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PRE-PROCESSOR FOR INBOUND SALES ORDER 
REQUESTS WITH LINK TO A THIRD PARTY 
AVAILABLE TO PROMISE (ATP) SYSTEM 



DESCRIPTION 
BACKGROUND OF THE INVENTION 

Field of the Invetition 

The present invention generally relates to pre-processing electronic 
commerce requests and, more particularly, to a method and system for 
modifying electronic commerce requests before they are sent to an order 
processing system. 

Background Description 

Electronic Data Interchange (EDI) is a fast, inexpensive and safe 
method of communicating purchase orders, invoices, ship notices, test results, 
and other frequently used business documents between two trading partners 
without human intervention. EDI eliminates paperwork and informational 
delays by allowing two or more computers to communicate directly. This is 
accomplished by having all parties follow an agreed upon EDI data format and 
communication standard. 

Minimum requirements for EDI participation include a computer 
system such as a PC, mini or mainframe; translation software to map internal 
business transactions to and from EDI standard formats; communication 



software to send and receive EDI files, and support communication protocols; 
and communication hardware such as a modem and a telephone line. 
EDI has three essential components. First, there must be an EDI standard that 
defines a set of commonly agreed upon data format and communication 
standards. Second, there must be a communications information delivery 
system, which may include telecommunications hardware and software as well 
as general communication protocols. Finally, translation software is required, 
which transforms data into a format that can be read by an otherwise 
incompatible system or network at either end of a transmission. 

For example, a computer application creates a business transaction 
(document) which is loaded into a file. This file is processed by the EDI 
translation software where it is mapped into an EDI standard data format. This 
EDI record is then communicated over a telecommunication link to a 
predetermined business partner. This business or trading partner decodes the 
EDI record by processing it through their EDI translation software, and dumps 
the information into an internal file. This file is then loaded into the trading 
partners business application. 

As shown in Figure 1, electronic data requests are sent directly fi-om 
the customer to the order fijlfillment system for processing. Disadvantages of 
this approach include data replication of master, control, and configuration 
data to the EDI subsystem, and non-integration with the order fulfillment 
embedded processing rules. Specifically, in prior art systems, an EDI order 
from a customer is received, as shown in function block 101. In function block 
1 02, the EDI order is translated into an internal format. The internally 
formatted data is then loaded into the order fialfillment system, as shown in 
function block 103. In decision block 104, the order fulfillment system checks 
for errors, such is incomplete fields within the EDI order, or determining if the 
sender is asking for a product or service that does not exist. If there are no 



errors, the EDI order is processed manually in accordance with business rules. 
For example, if there is a request for a specific date and quantity, business rule 
1 might be to respond only if the date and quantity requested can be satisfied. 
Rule 2 might be to keep the date, and take whatever quantity that is available. 
Rule 3 might be to substitute a different part number for the original part 
requested if there are not enough of the original parts requested to satisfy the 
order. If the EDI order does contain errors, then, in function block 106, the 
operator must manually correct the order. For example, missing fields may be 
filled in, or information such as a correct customer address may be provided. In 
function block 107, the EDI order is resubmitted, where it is again checked for 
errors, as shown in function block 104. Steps 104, 106 and 107 are repeated 
until decision block 104 determines that the EDI order does not contain any 
errors. 

Several patents relate to the pre-processing of presentations, 
documents, and the like. These pre-processing systems are not, however, 
directly applicable to EDI, and have shortcomings with respect to EDI 
applications. U.S. Pat. No. 5,577,258 to Cruz et al. discloses an apparatus and 
method for pre-processing multimedia presentations to be delivered to 
customers such that delays due to interactive response time is virtually 
eliminated. This method, however, is not directly applicable to EDI 
applications.. 

European Pat. No. EP 0 863 678 A2 to Kung discloses a method for 
automated service provisioning for telecommunications companies. Data firom 
a caller is validated to determine whether the caller is an existing customer 
entitled to a requested service. Requests are converted into data compatible 
with the processor of the automated method. 

PCT Pat. No. WO 96/20952 to Lucas discloses a central pre- 
processing system with logistics for documents as well as system access based 
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on subscriber identities at the operator of telecommunications system. 
Document related data is pre-processed and stored, and rules for standardized 
processing of document information are provided. U.S. Pat. No. 5,594,910 to 
Fiiepp et al. discloses a distributed processing, interactive network and method 

5 of operation. The method discloses a way to provide access to large numbers 
of applications to a large number of users, and different methods to streamline 
the data accesses. U.S. Pat. No. 5,752,246 to Rogers et al. discloses a World 
Wide Web browser to fulfill requests from different clients, and a way of 
requesting, processing and presenting information on the WWW. U.S. Pat. No. 

10 5,5 1 7,406 to Harris et al, discloses a tool for handling mutual fiind related 

data, where a mutual fund trade is priced, extended and trade-acknowledgment 
is confirmed by a pre-processor. These patents are not, however, directly 
applicable to EDI, and do not provide the realization of the features or 
conveniences of an EDI system. 
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SUMMARY OF THE INVENTION 

It is therefore an object of the present invention is to provide an 
integrated system and method for pre-processing electronic data requests 
before they are sent to an order processing system. 
5 It is another object of the present invention to provide an interface to a 

system that provides a planning and forecast engine that determines if a 
material is available for a given quantity and delivery date. 

It is yet another purpose of the present invention to provide a system 
and method for making corrections to electronic data requests before they are 

10 sent to an order processing system. 

It is yet another purpose of the present invention to provide a system 
and method for rejecting electronic data requests so that they are not sent to an 
order processing system when certain criteria specified within the electronic 
data request cannot be satisfied. 

1 5 To this end, it is proposed to provide a computer implemented order 

interceptor that pre-processes Electronic Sales Orders (ESOs), an interface to 
a third party planning and forecast engine, a pseudo-sales order workbench 
that allows ESOs to be corrected before they are sent to the order processing 
system, and a reject acknowledgment system that rejects ESOs when the ESO 

20 contains errors or the ESO cannot be satisfied. 

Accordingly, in the preferred embodiment of the invention, a supplier 
enabled for electronic commerce using the SAP AG Corporation sales and 
distribution modules for order fijlfiUment can use the Electronic Sales Order 
(ESO) pre-processor (e.g. the order interceptor) to perform an asynchronous 

25 availability check (using, for example, the PROFIT Available to Promise (ATP) 

by International Business Machine Corp., or any other suitable third party 
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software package) before the sales order is posted to the order processing 
system. The ATP system is the planning and forecast engine that determines if 
a material is available for a given quantity and delivery date. The result of the 
ATP check is stored in the ESO and is later applied to the order processing 
system. The order interceptor derives the prerequisite data for the ATP check 
by supplementing the ESO with SAP master and configuration data. The result 
of the ATP check is also used to determine key information about the sales 
order, such as the sales organization, and division and distribution channels 
(sales area). 

In the preferred embodiment, the ESO pre-processor splits the ESO 
into multiple requests if there are multiple line items supplied by different 
delivery plants that are not configured to share the same sales area in SAP. 
Without this ftinction, the supplier would have to perform this activity 
manually. 

In addition to supporting a third party availability check and subsequent 
splitting of the ESO, the pre-processor provides a robust set of business rules 
that allows a supplier to configure how a request is managed. These business 
rules allow certain functions to be automated if specified criteria are satisfied. 
For example, a new sales order request from a low-tiered customer can be 
configured for manual service prior to posting. The same request from a 
high-tiered customer can be configured for manual review only under certain 
conditions, such as if the requestor falls under minimum order quantity levels, 
while the same request from another customer in the same condition could be 
configured for automatic routing. 

In the preferred embodiment, FSOs held for review can be viewed and 
edited by using the Workbench component of the pre-processor. The 
Workbench replaces the generic tool supplied by SAP AG Corporation, The 
Workbench provides a customer purchase order view of the ESO that looks, 



feels and behaves like actual order entry screens. In addition to displaying the 
ESO, the Workbench displays messages generated from the pre-processor 
describing why the ESO was held for review. When a message is executed, the 
Workbench branches to the appropriate data correction screen. The branch 
could be to a specific segment in the ESO, to master data, or to configuration 
data. After the condition is corrected, the Workbench re-executes the ESO 
pre-processor. I'his continues until all messages are corrected or marked 
reviewed. The supplier can decide to either accept the request, reject the 
request, or accept individual line items. 

Finally, in the preferred embodiment, if the request is rejected, then an 
auto reject acknowledgment is generated without posting the ESO to the order 
processing system. If the request is accepted, then the ESO is routed to vendor 
supplied function modules for sales order posting the ESO to the order 
processing system. Partial accepts are communicated back to the customer 
through the outbound acknowledgment process. 

There are several features of the order interceptor of the present 
invention that distinguish it from other pre-processors of this kind. First, the 
order interceptor is implemented inside of SAP's table space after the ESO is 
created by SAP's IDOC/ALE application layer (see Figure 6, 600, 601, 602, 
604 and 608) and before sales order posting. All other pre-processors of this 
kind are implemented outside of SAP's IDOC/ALE application layer, typically 
on flat files that are in ESO format. With this approach, all tracking, logging 
and other capabilities inherent in SAP's IDOC/ALE application layer are lost. 
The order interceptor of the present invention is thus capable of adding, 
changing, and deleting ESO data segments. The hierarchy of the ESO data 
segments are redetermined each time changes are applied to the ESO. All 
changes to the ESO are logged in the ESO status segments, thus providing a 
full audit trail of activity. The program that rebuilds the ESO is packaged 
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individually and can be used by other pre-processors that have the need to 
manipulate the ESO in this manner. 

Another feature of the present invention is that the order interceptor 
supports an asynchronous interface to a third party ATP System running on a 
remote server. The result of the availability check is stored in uniquely 
configured ESO data segments and applied to the sales order during posting. 
Before initiating the availability check, the ESO order interceptor analyzes the 
ESO to see if ATP commits are present. If found, the availability check is 
bypassed and the sales order is posted with the ATP commits already on the 
ESO. In addition, the ESO can be split into multiple ESOs based upon the 
results of the ATP check. The business rules for when to split the ESO is 
implemented separately from how the ESO is split. 

A third feature is that the order interceptor performs various edits and 
audits based upon business rules configured by customer, logical message type 
and message code. For example, one of the unique features of the present 
invention is to configure the system to hold the ESO for manual review when a 
predefined condition arises before posting to the application. This gives the 
supplier the opportunity to perform error detection and correction above those 
supplied by SAP AG Corporation. The ESO order interceptor also provides 
various user exits for customer specific requirements using the SAP 
Corporation SMOD and CMOD transactions. The SMOD and CMOD 
transactions allow enhancements to be made to the base functionality of the 
software. For example, additional processing steps can be added to the base 
functionality of the software. After the additional processing steps, the 
processing associated with the base functionality resumes. 

Further, the workbench component of the order interceptor provides 
the supplier with a tool to change the ESO and perform any necessary error 
correction identified by the order interceptor. This workbench replaces a 



generic tool supplied by SAP. The workbench provides a unique view of the 
ESO so that the user does not have to know the structure and qualifiers of the 
ESO. The screens are presented in pre-sales order format thus giving them a 
preview of the "to be" sales order. In addition, the workbench provides 
branches to various SAP AG Corp. master and configuration data for error 
correction and analysis, as well as a branch to the generic tool supplied by SAP 
AG Corp. for ESO editing. Another unique feature of the workbench is the 
auto-reject function. The supplier can reject a request and generate an 
acknowledge without posting to the application, all within the vendor's 
1 DOC/ALE layer. 

Various objects, features aspects and advantages of the present 
invention will become more apparent from the following detailed description, 
in conjunction with the accompanying drawings, of a preferred embodiment of 
the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advantages will be better 
understood from the following detailed description of a preferred embodiment 
of the invention with reference to the drawings, in which: 

Figure 1 is a flowchart illustrating how EDI orders are processed in 
accordance with conventional methods; 

Figure 2 is a block diagram showing a preferred embodiment of order 
interceptor system components; 

Figure 3 is a flowchart illustrating the overall process of pre-processing 
orders before they are posted to the order processing system according to the 
present invention; 

Figure 4 is a flowchart illustrating the process of the pseudo-sales order 
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workbench; 

Figure 5 is a flowchart of the reject acknowledgment process; 

Figure 6 is a block diagram showing a preferred embodiment of the 
relationship of the software modules that comprise the order information 
5 processing system; 

Figure 7 shows a preferred embodiment of a pre-sales overview menu 
screen displayed from the pseudo-sales order workbench; 

Figure 8 shows a preferred embodiment of a pre-sales order delivery 
schedules screen displayed from the pseudo-sales order workbench. 



1 0 DETAILED DESCRIPTION OF PREFERRED 

EMBODIMENTS OF THE INVENTION 

With reference now to the drawings, and more specifically to Figure 2, 
the order interceptor system which embodies the principles of the invention is 
shown. The order interceptor system includes an order interceptor 201 for pre- 

1 5 processing ESOs before they are posted to the order processing system 209. 

I'he order interceptor 201 includes a translator 202 for translating a customer's 
order data into an internal format. The order data is received via a standard 
EDI format transmission 203, After translating the customer's order data into 
an internal format, the order interceptor 201 begins to process the data by 

20 customer specific business rules contained in the business rules database 210. 
For example, a new sales order request from a low-tiered customer can be 
configured for manual service prior to posting. The same request from a 
high-tiered customer can be configured for manual review only under certain 
conditions, such as if the requestor falls under minimum order quantity levels. 
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while the same request from another customer in the same condition could be 
configured for automatic routing. If the order interceptor 201 determines that 
an ATP check is needed, the order interceptor 201 will interface with ATP 
system 204 to collect the needed data from the data translator 205. The ATP 
5 system 204 serves as a planning and forecast engine that determines if a 
material is available for a given quantity and delivery date. 

If the order interceptor 201 determines that any of the business rules 
contained in the business rules database 2 1 0 fail, or there are any other 
processing problems, the order interceptor 201 interfaces with a sales order 

10 workbench 206, which allows corrections to be made. The pseudo-sales order 
workbench 206 allows for manual review, modification, and/or corrections to 
the customer's order data within the internal format. The customer's order 
data is presented in a format as if the end user is processing an order online 
within the order processing system 209. The pseudo-sales order workbench 

1 5 206 allows for field modifications as well as fijnctions such as rejecting a 

customer's order. 

If processing calls for the order to be rejected, the order interceptor 
201 interfaces with the reject acknowledgment system 207 to perform that 
reject so that the ESO request is not processed by the order processing system 

20 209. The reject acknowledgment system 207 takes the customer's order data in 

an internal format and creates an acknowledgment containing reject codes that 
indicate why a customer's order has been rejected. For example, one reason an 
order may be rejected is that there is not enough inventory on hand to satisfy 
the customer's order, and appropriate customer values. The reject codes are 

25 then transmitted back to the customer in a format the customer can understand 
so that the customer knows why the order has been rejected. The reject 
acknowledgment system can also reject any changes that are made to existing 
orders. Further, the reject acknowledgment system can also be used to reject 

BU999-021 
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customer forecast requests. For example, a customer may query if a certain 
quantity of parts can be provided, say, in 4-6 months. The reject 
acknowledgment system 207 again creates the reject codes, and then transmits 
them back to the customer in a format the customer can understand so that the 
customer knows why the forecast has been rejected. 

After the order interceptor 201 has pre-processed the customer's data, 
as described above, a router 208 routes the data to the designated order 
processing system 209, such as the IBM Corporation's OEMLS order 
processing system 21 1 or the SAP AG Corp. order processing system 212, by 
interpreting the customer specific configuration. For example, if a customer has 
a request for parts to be delivered on his dock as the request date, this can be 
called the dock date. A ship date may be defined as when a customer wants the 
parts shipped from a supplier. Another configuration may be based on transit 
time, which can be factored in to the order so that the customer will receive the 
order on or before the date requested. 

Preferably, the present invention uses IBM RS6000 engines running 
under a common umbrella, utilizing the AIX operating system (the IBM Corp. 
version of the UNIX operating system), and connected with a high speed 
computers, such as stand alone UNIX or Windows NT work stations, or 
workstations in a network. Mainframes, including IBM AS400 and ES9000 
computers, may also be utilized. 

In Figure 3, the major steps involved in the pre-processing of an 
incoming sales order are shown. The process starts when the order interceptor 
translator 202 receives a standard EDI transmission 203. Upon receipt, the 
translator 202 translates the EDI transmission 203 data into an internal format, 
as shown in function block 304. Fields such as sales area and delivering plant 
are derived and added back to the inbound ESO, and fields such as order 
quantity and ship date may be altered. 
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In ftinction block 305, the order interceptor 202 processes the data 
contained within the EDI transmission 203. During processing, the order 
interceptor 201 determines if an ATP check is needed, as shown in decision 
block 306. The ATP system, shown in function block 204 is the planning and 
forecast engine that determines if a material is available for a given quantity 
and delivery date. If the result of the test performed in decision block 306 
indicates that an ATP check is required, the order interceptor 201 interfaces 
with the ATP system 204. In decision block 308, the ATP system 204 tests to 
determine if the ESO data needs to be translated into an internal format. If yes, 
the ESO is translated by the data translator 205, as shown in ftinction block 
307. After data is added in fimction block 307, or if the test in decision block 
306 indicates that ATP processing is not required, or if the test in decision 
block 308 indicates that data does not need to be added, a test is then made in 
decision block 309 to determine if there are any other processing problems, or 
if any of the business rules 210 have failed. 

If it is determined in decision block 309 that the ESO does not satisfy 
all of the applicable business rules 210, or if the ESO is incomplete, in error, or 
requires manual review, then the order interceptor 201 creates a workflow item 
that can be executed from the in-basket of a responsible person so the 
workflow item can be reviewed and modified by using the pseudo-sales order 
workbench 206, as shown in function block 310. 

Within the pseudo-sales order workbench 206, a test is made in 
decision block 31 1 to determine if the ESO has been rejected. The 
pseudo-sales order workbench 206 allows for manual review, modification, 
and/or corrections to customer order data within an internal format. The 
customer*s order data is presented in a format as if the end user is processing 
an order online within the order processing system 209. It allows for field 
modifications as well as functions such as rejecting a customer's order. If the 
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ESO is rejected, then an acknowledgment is generated back to the customer 
without posting the ESO to the order processing system 209, as shown in 
function block 3 1 2. If the ESO is not rejected by pseudo-sales order 
workbench 206, then the ESO is transmitted to the order processing system 
5 209 and posted to the application, as shown in function block 313. After the 

appropriate action in function block 312 or 313, the process stops, as shown in 
termination block 3 1 4, 

Figure 4 shows a functional flow diagram of the pseudo-sales order 
workbench 206. When ESO errors are encountered, workflow items are 

10 created by the SAP Workflow, as indicated in function block 402. The 

workflow items are sent to the in-basket of the responsible person. When the 
work item is executed, as shown in function block 401, the work flow is 
displayed on a user terminal, as indicated by step 407. ESOs can also be 
displayed from the SAP workflow 402 that satisfy selection criteria that a user 

1 5 inputs into display block 403. Work flow messages are created under pre- 
defined conditions and routed to the responsible person for action. The 
responsible person can view and execute their messages from their SAP Office 
Inbox (not shown). When the message is executed, the user is branched to the 
appropriate application to correct the condition. In a preferred embodiment of 

20 the present invention, a workflow message is created when the order 

interceptor 201 encounters an error or determines that a manual review of the 
ESO is required. The user can also input selection criteria via the an input 
screen, as shown in step 403, to display ESOs that satisfy the selection criteria, 
as shown in function block 401. The ESOs are stored in accordance with the 

25 SAP AG Corp. ESO tables ESO Control 404, ESO Data 405, and ESO Status 

406. These tables validate the ESO structure, and pass control to ALE where 
the ESO can be processed into the appropriate business object, 
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such as a sales order or a purchase order acknowledgment, etc. The error 
message table 4 1 5 displays the error messages, as shown in function block 408. 
Once the error messages have been displayed, the user can also view the fields 
409 associated with the ESOs on the pseudo-sales order workbench 206, as 
5 shown in function block 409. The user can also perform various operations on 

the ESO, as indicated in function block 410. A test is then made in decision 
block 41 1 to determine if the ESO complies with the configuration rules and 
updates. If the ESO does not satisfy the configuration rules, a message is sent 
to the Pseudo-sales order Workbench, as shown in function block 412, If the 

10 ESO satisfies all configuration rules and updates, then the ESO is updated in 

tables 404, 405, 406 and 415. The process returns, as shown in function block 
414. If the user specified selection criteria via display 403, then the return is to 
the user's display terminal 403. If the SAP workflow 402 created the work 
item, then the return is back to SAP workflow 402. 

15 Figure 5 is a flow diagram of the Reject Acknowledgment System 207. 

The reject acknowledgment process takes an ESO that was rejected in the 
order interceptor 201 and creates a corresponding outbound ESO containing 
the reject codes and appropriate values. The reject acknowledgment process 
can be used to reject incoming ESOs with types sales orders, sales order 

20 changes, or forecasts. An inbound ESO with one of these types can be rejected 
from the order interceptor 201 by entering a reject code for the ESO. As 
shown in function block 501, the rejected inbound ESO is read from the tables 
404, 405, and 406. In decision block 505, the ESO is analyzed to determine if 
it was a web order. If yes, the ESO is closed, and no acknowledgment is sent, 

25 as indicated in function block 406, If decision block 505 determines that the 
order is not from the web, customer configuration table 508 is read to 
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determine the customer configuration for responses. In decision block 507, a 
determination is made whether the customer has requested the 
acknowledgment to contain the values of the SAP order book, or the original 
values that the customer sent in for the ESO. If the customer has requested to 
have the original ESO values sent in the acknowledgment, the original values 
that the customer sent in for the ESO are read and used, as indicated in 
function block 509. If the customer has requested that the values from the SAP 
order book be sent in the acknowledgment, the SAP order tables 51 1 are read 
and these values are used, as indicated in function block 510. Once the 
appropriate data is obtained for the acknowledgment from either function 
block 509 or 510, the outbound ESO acknowledgment is created in block 512 
using the reject codes fi-om the rejected ESO, and the ESO configuration table 
513 is updated with the acknowledgment ESO number. The reject 
acknowledgment system allows the response to the customer with the reason it 
was rejected without sending the customer's order request to the order 
processing system 209. 

The following is a description of a preferred embodiment of the 
software modules used to implement the claimed invention. It will be apparent 
to those skilled in the art that the individual software modules could be 
designed and arranged so that they may individually provide different 
functionality, while the overall combination of software modules maintains the 
functionality recited in the claims. 

A block diagram of how the software modules interface with each other 
is provided in Figure 6, In general, inbound sales order requests that are to be 
fulfilled in SAP are routed as a flat file to the operating system where SAP is 
installed. The flat file representing the ESO is in SAP's published ORDERS02 
ESO format for both new and change order requests and DELFOROl for 
scheduling agreement forecasts and just in time deliveries. ORDERS02 and 
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DELFOROl formats consist of various data segments comprising the ESO. 
Example data segments in ORDERS02 are: ElEDKOl (header general data), 
E1EDKI4 (header organization data), ElEDPOl (item general data), and 
E1EDP20 (item schedule lines). Example data segments in DELFOROl are: 
5 E 1 EDK09 (header data for JIT suppliers), E 1 EDP 1 0 (item data for JIT 

suppliers), and El EDP 1 6 (item schedules for JIT suppliers. Typically, these 
requests originate from EDI, but they can originate from any external interface. 
The ESOs are a derivative of SAP's ESO ORDERS02 format for new and 
change orders and DELFOROl for scheduling agreement forecast and Just In 

1 0 Time (JIT) releases. 

The EDI DATA INCOMING module 601 is a standard SAP function 
module that initiates the processing of the flat file representing the ESO. The 
EDI_DATAJNCOMING module 601 calls the RSEINBOO module 602, 
passing the ESOs to be processed. 

15 The RSEINBOO module 602 is the SAP Corp. standard program to 

process inbound ESOs irrespective of the application. Its main purpose is to 
load the file representation of an ESO into SAP ESO tables 404, 405 and 406, 
validate the ESO structure, and pass control to ALE where the ESO can be 
processed into the appropriate business object, such as a sales order or a 

20 purchase order acknowledgment, etc. If errors occur during the process, the 

RSEINBOO module 602 creates a workflow item which can be processed by an 
administrator using the standard ESO workbench module 606. ALE provides 
robust configuration support in determining how and when the ESO is 
processed. For inbound sales order requests, all customers will be configured 

25 to be routed through the pre-processor, ZJDOC__INPUT_PRE_PROCESS 
module 603. This module is the first in a series of locally developed modules 
that perform the pre- and post-processing of an ESO prior to posting as a sales 
order. This processing supplements the SAP supplied fianction modules 
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IDOC JNPUT_^ORDERS/ORDCHG/DELINS (not shown) by manipulating 
the ESO before SAP's processes are called. 

After the RSEINBOO module 602 validates and creates the ESO, 
control is passed to the IDOC^INPUT module 604, which is inside SAP's 
IDOC/ALE layer. Modules 600, 601, 602, 604 and 608 comprise the 
IDOC/ALE layer. Here, configuration tables are analyzed to determine how to 
process the inbound ESO. Again, for inbound sales order request, ALE will 
pass initial control to the pre-processor function module Z_ 
IDOC_INPUT_PRE_PROCESS module 603 for local processing. 

When ESO errors are encountered by the RSEINBOO module 602, 
workflow items are created by the workflow module 605 and sent to the 
in-basket of a responsible person. When the work item is executed, the IDOC 
Workbench module 606 generates a display on a user terminal. The EDI 
administrator can view the status of the ESO along with error text to determine 
the cause of error. The administrator can correct individual data segments of 
the ESO and initiate reprocessing of the ESO. The IDOC workbench module 
606 enables an EDI administrator to manage raw data, but is not intended for a 
sales order entry person. One would have to know the relationship of the ESO 
segments as well as understand code qualifiers. For example, data segment 
E1EDPI9, qualifier '001' represents customer material and qualifier '002' 
represents internal material. The IDOC Workbench module 606 is only 
intended to correct data errors that local processing does not handle. For 
example, a segment hierarchy error is detected before the pre-processor is 
called. All application related errors, such as duplicate PO number, will be 
handled in customer purchase order workbench module 607. 

When work items related to IDOC workbench module 606 are 
executed, the IDOC_MANUAL_INPUT module 608 is called. This function 
module passes control to the IDOC workbench module 606 and awaits to 
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process the results. If the return code indicates the ESO is to be processed, 
control is passed to the IDOC INPUT module 604, and the appropriate 
application is called via ALE. If the ESO is processed successfully by the 
application, then the IDOC_MANUALJNPUT module 608 updates the status 
5 of the work item to complete, indicating that it can be removed from the 

in-basket. If no action is taken from the IDOC Workbench module 606, the 
work item remains in the in-basket in an in-process status. If an error occurs 
during the application process, then the current work item is marked complete 
and a new work item is created in a ready status and displayed in the in-basket. 
1 0 This process is also used to model the Z__ IDOC_MANUAL_INPUT module 

609 and the Z_ IDOCJNPUT module 610 used with local processing. 

It should be noted that the following numbers correspond to the 
following activities cited hereafter in the specification: 

850 - New Sales Orders 
1 5 855 - Acknowledgment to sales order 

860 - Change Order 

865 - Acknowledgment to change order 

830 - Forecast 

870 - Response to Forecast 



20 ZO- ESO I leld for Order interceptor 

Zl- ESO in Pre-Process Status 

Z2- ESO Held for Pseudo-sales order Workbench 

Z3- ESO Rejected in Pre-Processing 

Z4- ESO in Pre-ATP status 
25 Z6- ESO Closed Without Posting to Application 

Z7- ESO Closed Without Posting and Routed to OEMLS 
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For all inbound sales order requests, the IDOC/ALE layer will be 
configured to pass control to the local Z IDOC JNPUT_PRE PROCESS 
module 603. For now, the pre-processor module 603 will support requests 
using ORDERS02 and DELINS ESO format. Currently, this includes 850/862 
new order requests, 860 change order requests and 830/E forecast and JIT 
scheduling releases. 850 also includes create contract and create with reference 
to a contract. 

The Z_IDOC__rNPUT_PRE_PROCESS module 603 is where local 
pre-order processing occurs that is not supported by standard SAP. The data in 
the ESO is audited above standard SAP edits and audits. In addition, 
conversions unique to particular users will be performed. Fields such as sales 
area and delivering plant are derived and added back to the inbound ESO, 
Fields such as order quantity and ship date may be altered based upon local 
business rules such as, for example: (i) round the order quantity up to the 
minimum order quantity defined in the materials sales view, or (ii) offset the 
request date with the transit time. All these conversions occur prior to the 
request being routed to the PROFIT/ATP module 618. 

If the ESO is incomplete, in error, or requires manual review, then the 
Z IDOC JNPUT PRE PROCESS module 603 creates a workflow item 605 
that can be executed from the in-basket of the responsible person to review and 
modify the request by using the customer purchase order workbench 607. If 
the ESO is rejected, then an acknowledgment is generated back to the 
customer without posting the document to the application. The ESO*s status is 
set to Z3. If the ESO is marked complete, then the ESO's status is set to Z6 
and not posted to the application. Likewise, if the ESO is rerouted to OEMLS 
(211), then the ESO's status is set to Z7 and not posted to the application. 
Otherwise, if the ESO is complete and accepted by the User, the request is first 
routed to module 613 if one or more materials on the ESO is on the 



21 

PROFIT/ATP module 618, and then to the post- ATP module 615 to post the 
document. 

The User can access ESOs held by the pre-processor 603 by executing 
work items in their Office inbox or by using the "Analyzer" drill-down report 
module 61 1 (trx ZEDU). This module provides a front-end to the inbox 
process that allows search parameters, such as delivery plant document type, 
and ESO status and displays the ESOs in report format with drill-down and 
mass processing capabilities. From the list, the User can branch to customer 
purchase order workbench module 607, existing sales order transactions, or to 
the native IDOC workbench module 606. The report gives a visual 
representation of the ESO's status by using traffic light icons and can display 
why the ESO was held by the pre-processor module 603. This can help the 
user prioritize which ESOs to process first and so on. In addition, the report 
can also be used to compare data on the ESO to data on the existing sales 
order for change type of requests. 

If pre-processor module 603 detects an error or manual review 
condition, the workflow module 605 creates a workflow that is made available 
to the in-basket of the responsible person. Once the work item is executed, the 
customer purchase order workbench module 607 is provides a display to a user 
terminal. The user interface is modeled after the incompletion log for 
processing sales orders. The initial screen will display a list of messages 
identifying why the request was held along with key information from the 
ESO's control and data record segments. If the user is authorized, each item in 
the list can be executed and taken to the appropriate screen to correct or 
review the data. After each correction, the ESO is reprocessed by 
pre-processor module 603. After executing the message, control goes back to 
the main screen. Messages will be removed from the list if it now passes all the 
edits and audits for that rule. If the request was held for manual review, the 
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User can navigate to an overview screen to review the request using screens 
similar to those in SAP sales order process. There, certain fields can be 
updated, such as sales area and delivery plant. Some fields however, can only 
be changed in conjunction with executing specific messages. For example, the 
5 customer's PO number can be changed only if a duplicate error is detected. For 

860 change order requests, the corresponding sales order information can be 
displayed to assist the user in analysis by drilling down on the order number 
field. Additionally, a branch to the native SAP IDOC Workbench can be made 
by drilling down on the ESO number, as provided by the analyzer drill down 
1 0 report module 611. Access is now available to all ESO segments and data that 
may not have been available in customer purchase order workbench module 
607. 

To reject all or part of the request, the user must provide a reject 
reason code at either the header or line level. A configuration table will be 

1 5 checked by customer and transaction code to see if partial rejects are allowed. 
If all line items are rejected, or the header is rejected, then an 855/865 
acknowledgment is generated once the request is released from the customer 
PO workbench module 607. In this case, the request is never posted to the 
sales order system. For 850 new orders, if any of the line items are accepted, 

20 then the entire order is loaded into SAP with rejected line items flagged as 

rejected with the appropriate reason code. The acknowledgment will be sent as 
part of the sales order post process. For 860 change orders, only the line items 
accepted are passed to the SAP sales order process. All rejected line items 
along with their reject codes are stored for subsequent processing. Ajfter the 

25 sales order change is posted, the acknowledgment process will pick up those 

lines rejected in workbench module 606 and merge them along with the 
accepted line items on the sales order and create one acknowledgment for the 
order. Once the user releases the request, the order is routed back to 
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pre-processor module 603, and if no error or review conditions are detected, 
the request routed to ATP module 618, and finally to the SAP supplied 
function modules 616 and 617 to post the order. 

If the user rejects the customer's request in the customer purchase 
order workbench module 607, then the appropriate outbound ESO 
acknowledgment (855/865/870) is generated automatically by the 
Z_ACK__REJ_CUST_PO module 612. The ESO can be rejected at either the 
header level or by rejecting all line items on the ESO. Rejected ESOs never get 
posted to the sales order application. The ESO's status is set to Z3. Module 
612 supports two methods of acknowledging rejects back to the customer 
based upon customer configuration table 508. If the value is 'A* or blank, then 
the acknowledgment is built fi-om the original ESO with the appropriate reject 
code. If the value is V\ for new order requests, the acknowledgment is built 
from the original ESO without a reject code. For change order requests, the 
acknowledgment is built using the existing sales order without a reject code. 

When work items related to the customer purchase order workbench 
are executed, the Z JDOC_MANUAL_INPUT module 609 is called. This 
module passes control to the customer purchase order workbench module 607, 
and awaits to process the results. If the return code indicates the ESO is to be 
processed, control is passed to the ZJDOC_INPUT module 610 which calls 
the pre-processor in this case. If the ESO is processed successfully by the 
application, then the Z IDOC__MANUAL INPUT module 609 updates the 
status of the work item to complete indicating that it can be removed from the 
in-basket. If no action is taken fi*om the customer purchase order workbench 
module 607, the work item remains in the in-basket in an in-process status. If 
an error occurs during the application process, then the current work item is 
marked complete and a new work item is created in a ready status and 
displayed in the in-basket. 
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After the inbound request has successfully cleared the 
ZJDOCJNPUT PRE PROCESS module 603 and customer PO workbench 
module 607, and if one or materials on the ESO is on the PROFIT/ATP 
module 618, the Z_1D0C_INPUT_PRE_ATP module 613 is called. Here, the 
5 PROFIT/ ATP interface file ZATPDEM is used as the communication vehicle 

between SAP and the third party ATP system. For example, for IBM Corp,, 
the third party ATP system is PROFIT/ATP. The file is managed by 
PROFIT/ATP module 618. The rules for managing entries in the PROFIT/ATP 
interface file are the same rules used in the SAPMV45A module 617. The 

10 "save documenf ' user exit was changed to apply the PROFIT/ ATP results to 
the sales order. For requests already committed by the PROFIT/ATP module 
6 1 8 (requests from 9BD), a dummy reservation is created to bypass the 
PROFIT/ ATP module 618. In this case, the request is considered complete by 
the PROFIT/ATP module 618 and no response back is required. In this case, 

15 control returns back to pre-processor module 603, which directly initiates 

post-atp processing 615. Requests requiring PROFIT/ ATP module 618 action 
are added to the interface table and are sent to the PROFIT/ATP module 618, 
If the link is active and responding in a timely fashion, then control returns 
back to pre-processor module 603 which directly initiates post-atp processing 

20 at module 615. If the link is not responding, then pre-processor module 603 
reinitiates module 61 3 in a mode to indicate that the response is no longer 
synchronous and to trigger the ZMOM103 module 619 after responding. The 
restart ESOs in Z4 status (ZMOMI03) module 619 restarts the ESO process at 
the post-atp step. 

25 The module Z_FORMAT_ATP_DATA (not shown) is used to 

encapsulate the interface from SAP to PROFIT. The module interfaces entries 
in table ZATPDEM to the PROFIT/ATP module 618 via module 
Z PROFIT_DATA_EXTRACT (not shown). 
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The module Z PROFIT DATA EXTRACT (not shown) is a remote 
function used to pass reservation request from SAP to the PROFIT/ATP 
module 618. The use of MQSeries is transparent to the application. 

The PROFIT/ ATP module 618 services the request made by the 
5 Z_PROFIT_DATA_EXTRACT module (not shown). The PROFIT/ATP 

module 618 communicates its response by calling remote function call 
Z_PROFIT_DATA_LOAD (not shown). Module Z_PROFIT_DATA__LOAD 
(not shown) is called remotely from the PROFIT/ATP module 618 to update 
commit data for reservations in table ZATPDEM. This table is then used to 

1 0 communicate the commit data to SAP sales order processes. After the interface 
table is are updated, event Z_EDI_ATP_START (not shown) is started if the 
request to PROFIT/ ATP module 618 can not be performed in a synchronous 
mode, such as when the link is down or slow in responding. This event starts 
ZMOMI03 619 which restarts the process. 

1 5 If ihe ZJDOC JNPUT_PRE_PROCRSS module 603 determines that 

a previous request for a customer and given purchase order is pending an 
acknowledgment, then the inbound ESO's status will be set to 'Queued for 
Pre-Processor' (ZO). The definition of incomplete in this case means that a 
prior ESO has not been posted by the sales order application or the original 

20 sales order is incomplete or blocked for any reason. This feature can be 

disabled by changing the corresponding column in table 508 using trx ZEDL 
The ZMOMlOl module 614 will be scheduled as a reoccurring job run hourly 
to process ESOs are in this status. Each request will be checked for pending 
acknowledgments. If the request is cleared for process, then control is passed 

25 to the Z_IDOC_INPUT module 610 which calls the pre-processor and 

manages the ESO's status and work item; otherwise, the request is held until 
the next run of the ZMOMlOl module 614. 
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If one or more materials contained in the ESO are on the PROFIT/ATP 
module 618, then the ESO must be routed through module 613 from the 
pre-processor module 603, If the link is down or slow in responding, then the 
ESO status is set to Z4 to indicate awaiting response from the PROFIT/ATP 
module 618. Processing on the ESO is halted until all responses are received 
from the PROFIT/ ATP module 618. The response function module triggers the 
event Z EDI ATP START (not shown), which starts the ZMOM103 module 
619. The ZMOM103 module 619 selects all ESOs in status Z4 and analyzes 
the interface table to see if all schedules on the ESO have responses (0 commit 
is considered a valid response). If the request has all the responses, then 
control is passed to the Z_IDOC__INPUT module 610, which calls the 
post- ATP module 615 to post the ESO to the application. Otherwise, the ESO 
remains in a Z4 status until the next triggering of the ZMOM103 module 619. 

If processing of the ESO is suspended and a workflow item is not 
created, then the Z IDOC INPUT module 610 is used to restart the process. 
This module along with Z JDOC_MANUAL__INPUT module 609 which is 
used in conjunction with workflow module 605, is the local IDOC/ALE layer 
which mimics the corresponding modules in SAP. ESOs are currently 
suspended in 2 cases: 1) if an 860 change order can not be processed because a 
prior ESO is pending or the order is blocked, then the status is ZO; 2) if the link 
to the PROFIT/ATP module 618 is not responding in a timely fashion, then the 
status is set to Z4. The ZMOMlOl 614 and ZMOM103 619 modules use the 
PROFIT/ATP module 618 to restart the ESO processing by calling the 
appropriate function module based upon the status of the ESO. For example, 
the post- ATP module 615 is called if the ESO is in Z4 status, and the 
pre-processor module 603 is called if the ESO is in ZO. This function module is 
also responsible for creating workflow items and managing the ESO*s status 
based upon results from the application function module. 
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The Z IDOCJNPUT POST ATP module 615 performs four major 
functions: 1) applies the commit information from the PROFIT/ATP module 
618 back onto the ESO if one or more materials represented in the ESO are on 
the PROFIT/ATP module 618; 2) holds the ESO for manual review if key data 
changes from the PROFIT/ ATP module 618, such as the delivery plant and to 
split the ESO into multiple ESOs for new order requests if there are multiple 
line items on the ESO supplied by more than one delivery plant; 3) calls the 
appropriate SAP supplied function module to post the document (new and 
change orders, contracts, reference to contracts, and scheduling agreement 
releases), and 4) performs post processing logic based upon the results from 
the application function module, such as to create specialized work items if the 
call transaction fails, general cleanup etc. 

SAP supplies function modules IDOC_INPUT_ORDERS (not shown) 
to post new sales orders, IDOCJNPUT ORDCHG (not shown) to change 
existing sales order, and ID0C_INPUT_DEL1NS (not shown) to add FDS and 
JIT scheduling releases. User exits are available at key points in the process to 
allow local modifications as necessary. Several of the user exits are enabled to 
load additional data into the BDC session, such as delivery plant, delivery 
block, and fixed quantity indicator. For delivery schedules, 
IDOC INPUT DELINS (not shown) supports customer expected pricing 
condition EDI I with screen logic. No edits and audits are performed in these 
exits. These types of functions are performed by the pre-processor module 613 
and worked in the workbench module 607 before this stage. 

Function modules ZJDOC JNPUT_CONTRACT 616 and Z_ 
IDOCJNPUT REF CONTRACT 616 create contracts and create an order 
with reference to the contract, respectively. Both modules are derivatives of 
IDOC JNPUT_ORDERS 616and still share the same user exits. Additional 
logic was added to support the required fields and screen flows. 
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The SAP Supplied Function Modules with User Exits module 616 
functions with SAP function modules IDOC INPUT ORDERS 616 to post 
new sales orders, IDOC__INPUT_ORDCHG 616 to change existing sales 
order, and IDOC_INPUT_DELINS 616 to add FDS and JIT scheduling 
5 releases. User exits are available at key points in the process to allow local 

modifications as necessary. Module 616 enables additional data, such as such 
as delivery plant, delivery block, fixed quantity ind., additional partners, and 
pricing reference material to be loaded into the BDC session. For delivery 
schedules, IDOCJNPUT_DELINS (not shown) supports customer expected 

10 pricing condition EDIl with screen logic. No edits and audits are performed in 

these exits. These types of functions are performed by pre-processor module 
603 and worked in workbench module 606 before this stage. 

SAP supplies the Call Trx User Exits (SAPMV45A) module 617 to 
manage the sales order entry set of transactions, such as create, change and 

1 5 display sales orders, contracts, and scheduling agreements. User exits are also 
available at key processing points to address local processing requirements. 
Exits were modified to support our unique ATP Requirements. 

The following is a description of how the Order Interceptor Rules 
function, 

ESQ Audits and Adjustments 

The following audits and adjustments are performed on the ESO provided the 
preconditions are satisfied. If an audit fails or manual review is required, then 
the ESO is held for correction/review in the customer PO workbench module 
607. The condition must be corrected or marked reviewed in the customer PO 
workbench module 607 before the ESO can be released to the application for 
processing. Any time data is changed in the customer PO workbench module 
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607, order interceptor module 603 reapplies the audits. This cycle continues 
until all messages are corrected or marked reviewed. 

All these events occur after the ESO is created on the system and prior 
to the ESO posting to the application. 

These audits apply to all ESO types supported by the order interceptor 
603. At the present, this includes Z0RDERS2 for requests processed using 
VAOl, VA02, and VA41 (Sales Orders and Contracts) transactions and 
ZDELF0R2 for requests processed using transaction VA32 (Scheduling 
Agreements). 

Validate Logical Message Type 
Preconditions 

Audits The following logical message types are supported by the Order 
interceptor: 

ORDERS New Order 
ORDCHG Change Order 
DELINS Scheduling Agreement 
Pseudo-Sales Order Workbench Message 

Message ZV 327. Logical message type & and message code & not 
supported by the Order interceptor. The ESO must be marked complete in the 
Workbench and can not be posted to the application. 

Validate Entry in Local EDI Configuration Table 

Preconditions 

None 

Audits 

An entry must exist in the table 508 for the given Customer, the ESO's 
logical message type (edidc-mestyp) and message code (edidc-mescod), 
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Pseudo-Sales Order Workbench Message 

Message ZV 222. ZEDITCFG not configured for customer &, logical 
message type &, and message code &. The corresponding entry in ZEDITCFG 
must be made using trx ZEDI. -> Configuration -> By Customer/Msg/Material 
before the ESQ can be released from the Workbench. 

Validate EIEDSOlSummary Total Segments 
Preconditions 

Audit is performed if ElEDSOl is provided on the ESQ. 

Audits Verify the following summary segments (ElEDSOl-SUMID 
and SUMME) provided on the ESO from the EDI Translator match the totals 
computed by the Order interceptor; 

• 00 1 Total number of line items on the ESO 

• 004 Total requested quantity from delivery schedule segment 

on the ESO 

ZO I Total number of segments on the ESO not including 
summary segments 
Pseudo-Sales Order Workbench Message 
Message ZV 357. Order interceptor detected summary level totals 
mismatch. The ESO must be marked complete in the Workbench and can not 
be posted to the application. 

Validate External Partner Entries Using EDPAR 
Preconditions 

Audit is performed if ElEDKAI or ElEDPAI is provided on the ESO 
without field PARTN (LIFNR). 
Audits 
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The following header level partner functions (ElEDKAI-LIFNR) are 
cross referenced using EDPAR table to determine the SAP internal customer 
number: 

AG Sold-To 

• LF Supplier 

• AB Unloading Point 
WE Ship-To 

• SP Carrier 
RE Bill-To 
RG Payer 



The following item level partner functions (ElEDPAl-LIFNR) are 
cross referenced using SAP's EDPAR table to determine the SAP internal 
customer number: 

WE Ship-To 
RE Bill-To 
RG Payer 
Pseudo-Sales Order Workbench Message 
Message Z V 226. External partner number & invalid for partner 
function &. The corresponding entry in EDPAR must be made using trx 
VOED-> Partner -> Application -> Conversion or changing the corresponding 
LIFNR field on the ESO to match EDPAR. The message must be corrected 
before the ESO can be released from the Workbench. 



Find Existing Sales Order 
Preconditions 

Logical message type ORDCHG, 
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The following fields must exist in the ESO: 

Customer's PO (VBAP-BSTNK) 

Default Order Type (VB AP-AUART) 
Audits 

Possible candidates are selected from view M_VMVAA using the Customer's 
Sold-to, PO number, and default order type. If no entries are found, or more 
than I entry found, the ESO is held for the Pseudo-Sales Order Workbench. 
Pseudo-Sales Order Workbench Message 

Message ZV 242. Existing sales order not found for customer &, PO 
number &, and line &, From the Overview menu, correct the customer's PO 
number. 

Message ZV 299. Multiple sales orders exist for customer's PO & and 
line &. Process the error message and choose the appropriate sales order for 
processing. 

The matching sales order must be determined before the ESO can be 
released from the Workbench, 

Split Change ESO into Multiple ESOs 
Preconditions 

The ESO is split under the following conditions: 
Logical message type ORDCHG 
Multiple line items on the ESO 

Customer's PO and line item are found on separate discrete sales orders 

Audits 

For each line item on the ESO, the corresponding sales order is found using the 
Customer's PO and line item (VBAP-POSEX). If the line items span multiple 
sale orders, then the ESO is split into multiple ESOs, one per sales order. For 
example, if line items 1, 3, 4 were found on sales order 0090016323, line items 
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2,6 were found on 0090016524, and line item 5 was found on 0090016535, 
then 3 ESOs would be created. ESO A would contain line items I, 3, 4. ESO 
B would contain line items 2, 6. ESO C would contain line item 5, Each new 
ESO inherits all the header level segments from the original ESO such as 
partner functions and reference data. The original ESO is marked complete 
(status Z6 - Closed without Posting to Application) after all the ESOs are 
created successfully. From then on, the new ESOs are processed independently 
from one another. In this example, ESO A could be posted successfully where 
as ESO B and C be held for manual review. 

Pseudo-Sales Order Workbench Message See Find Existing Sales Order. 

This is covered under the Find Existing Sales Order Module. 



Find Existing Scheduling Agreement 
Preconditions 

Logical message type DELINS 



The following fields must exist in the ESO: 
• Customer's material number (VBAP-KDMAT) 
Optionally, Customer's PO (VBAK-BSTNK) 

Audits 

Possible candidates are selected fi-om view M_VLPMA using the following 
selection criteria: 

KDMAT Customer's material number 

KUNNR Sold-to 

KNREF Customer's description of partner (plant, storage 

• location) 
ABLAD Wildcard + Unloading Point 
ABRVW Wildcard + delivery schedule usage ID 
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KTEXT Wildcard + search term for product proposal 
BSTNK Optionally configured to use Customer PO number 
(T663A-BSTNKP) 

If no entries are found, or more than I entry found, the ESO is held for the 
Pseudo-Sales Order Workbench. 
Pseudo-Sales Order Workbench Message 

Message ZV 328. T661 W not configured for vendor &, plant &, and 
unloading point &. Process the error message (link to trx OVAI) and make the 
appropriate entry so that the internal Sold-to can be determined. 

Message ZV 329. T663 A not configured for sold-to & and unloading 
point &. Process the error message (link to trx 0VA9) and configure the rules 
for sold-to and unloading point. 

Message ZV 330. No scheduling agreement could be found. Process 
the error message and change the selection criteria so that the appropriate 
scheduling agreement can be chosen. 

Message ZV 331. No scheduling agreement could be found using 
customer's PO number. Process the error message and change the selection 
criteria so that the appropriate scheduling agreement can be chosen. This 
includes the customer's PO number. 

Message ZV 332. No unique scheduling agreement could be 
determined. Process the error message and select the appropriate scheduling 
agreement from the list. 

Message ZV 334. No unique scheduling agreement could be found 
using customer's PO. Process the error message and choose the appropriate 
scheduling agreement from the list. 
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Message ZV 361 . Scheduling agreement contains multiple lines for the 
same customer's material number Process the error message and choose the 
appropriate line item. 

Message ZV 363. The Ship-to on ESO does not match the Ship-to on 
the scheduling agreement. Process the error message and change the Ship-to 
on the ESO. 

The matching scheduling agreement and line item must be determined 
before the ESO can be released from the Workbench. 

Required Segments in ESO (ORDERS and ORDCHG) 
Preconditions 

Audit is performed for ORDERS and ORDCHG logical messages. 
Audits 

The following ESO segments are required: 

E 1 EDK AI Order Header 

E 1 EDPO 1 Line Item (One or more) 
Pseudo-Sales Order Workbench Message 

Message ZV 213. Required segment & not found in ESO. The ESO must be 
marked complete in the Workbench and can not be posted to the application. 

Required Segments in ESO (DELINS) 

Preconditions Audit is performed for DELINS logical message. Audits The 
following ESO segments are required: 

E 1 EDK09 Release Header 

EIEDPIO Line Item (One per ESO) 

E1EDP16 ScheduleJlT/FDS Line 
Pseudo-Sales Order Workbench Message 

Message ZV 213. Required segment & not found in ESO. The ESO 
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must be marked complete in the Workbench and can not be posted to the 
application. 

Required Fields in ESO (ORDERS and ORDCHG) 
Preconditions 

Audit is performed for ORDERS and ORDCHG logical messages. 
Audits 

The following ESO fields are required: 





Description 


Segment 


Field 


Notes assigned 










from 




Customer No 


ElEDKAl 


parvw = 'AG* 


if not provided, 








partn (converted 


assigned from 








from 


edidc-sndprn 








lifnr using 










EDPAR) 






Customer's PO 


E1EDK02 


qualf- 'OOr 






No 




belnr 




L-i 


Customer' s Line 


ElEDPOl 


posex 






No 
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Customer's 


E1EDP19 


qualf= 'OOrif 


required if 


Material 




configured for 


internal material 






customer's 


not provided 






material; 


qual^ '002* 






qualf-'005' if 








configured for 








IBM catalog 








number 





Pseudo-Sales Order Workbench Message 

Message ZV 244. Required field & not supplied in ESO. The ESO must 
be marked complete in the Workbench and can not be posted to the 
application. 

Message ZV 340, Determining material (&) not supplied in ESO. The 
ESO must be marked complete in the Workbench and can not be posted to the 
application. Optionally, check to see if the local configuration is correct in 
ZEDITCFG for this customer and transaction. 

Required Fields in ESO (DELINS) 
Preconditions 

Audit is performed for DELINS logical message. 
Audits 

The following ESO fields are required: 



Description 


Segment 


Field 


Notes 
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Customer No 


ElEDKAI 


parvw = 'AG' 
partn (converted 
from lifnr using 
EDPAR) 


if not provided, 
assigned from 
cdidc-sndprn 


JfT/FDS 
Indicator 


EIEDPIO 


screl 




Customer's 
Material 


EIEDPIO 


idnkd 


required if 
internal 
material not 
provided 
idnlf 



Pseudo-Sales Order Workbench Message 

Message ZV 244. Required field & not supplied in ESO. The ESO must be 
marked complete in the Workbench and can not be posted to the application. 

Unique Tracking Number per ESO 
Preconditions 

Audit is performed if tracking number is provided in ESO. 
Audits 

The tracking number is generated from the EDI Translator in 
El EDK02-BELNR and QUALF for tracking purposes across the various 
systems. The tracking number must be unique per ESO, The tracking number 
is stored in ZEDIACKR-TRACKNO and can be up to 35 characters in length. 
Pseudo-Sales Order Workbench Message 
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Message ZV 368, Tracking number already assigned to ESO. The ESO must 
be marked complete in the Workbench and can not be posted to the 
application. 

Revision Number in Sequence 

Preconditions Audit is performed under the following conditions: 

• Revision number provided in the ESO 

• Logical message ORDCHG 

• Local EDI configuration set to process changes in sequence 
(ZEDITCFG-ZACKPEND) 

• Customer's PO number provided 
Existing Sales Order determined 

Audits 

The revision number is provided from the EDI Translator in 
El EDK02-BELNR and QUALE 'ZOl*. Its purpose is to facilitate processing 
changes from customers in sequence for those customers requiring this feature. 
The initial offering only checks that the revision number is greater than the last 
revision number processed for this sales document. The audit will be more 
robust as we understand our trading partner's requirements. The revision 
number is stored in ZEDIACKR-REVISION and can be up to 35 characters in 
length. 

Pseudo-Sales Order Workbench Message 

Message ZV 358. Change revision level is out of sequence. The ESO must be 
marked complete in the Workbench and can not be posted to the application. 

Determine Order Type 

Preconditions Order type is determined under the following conditions: 



BU999-021 



40 

• For logical message ORDERS when segment E 1 EDK 1 4, qualf '0 1 1\ field 
ORGID is NOT provided on the ESO 

For logical message ORDCHG and DELINS, the existing sales document 
found 
Audits 

For new sales order requests, the order type is determined based upon the 
ESO*s logical message type (edidc-mestyp) and message code (edidc-mescod). 
If the message type is ORDERS and message code not equal to BPO (for 
blanket PO), then the order type is defauhed to 'OR* for standard order. If the 
message type is ORDERS and message code is BPO, then the order type is 
defaulted to 'ZBO' for contract. A--er the internal material is determined, the 
default order type can be overridden from the local EDI Configuration 
table/field ZEDITCFG-ZOVRAUART (rule is only applicable at material 
level). 

For changes to an existing sales document, the order type is taken from 
the existing document. For example, a change to an existing standard order 
would be *0R or a change to a scheduling agreement (new release) would be 
*LZ' and so on. 

Pseudo-Sales Order Workbench Message 

None 

Determine Sales Area 
Preconditions 

The Sales area is determined under the following conditions: 
For logical message ORDERS when the following segments are NOT 
provided on the ESO (segment E1EDK14, QUALF xxx, field ORGID) 
Sales Org QUALF '008' 
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• Distribution Channel QUALF ^007' 
Division QUALF'006' 

For logical message ORDCHG and DELINS, the existing sales document 
found 
Audits 

For new sales order requests, the Sales area is determined from table 
EDSDC, I'he keys to this table is KUNNR (Customer number) and LIFNR 
(Vendor number sent with EDI). The Customer number is the Sold-to number 
and the Vendor number represents our Sold-to number at the Vendor. LIFNR 
is taken from the LF partner (ElEDKAI-PARTN) field on the ESO. If this 
field is not provided, the LIFNR is taken from the AG partner 
(ElEDKAI-LIFNR) field on the ESO. Together, these fields determine the 
Sales Area. For changes to an existing sales document, the Sales area is taken 
from the existing document. 
Pseudo-Sales Order Workbench Message 

Message ZV 233, Default sales area could not be determined for Customer & 
and Vendor &. Process the error message and make the corresponding entry in 
EDSDC using trx VOED-> Partner -> Application -> Customer/Supplier or 
from the Overview Menu, choose Header -> Partner and change the 
corresponding LIFNR field on the ESO to match EDSDC. The message must 
be corrected before the ESO can be released from the Workbench. 

Determine Internal Material 

Preconditions The internal material number is determined under the following 
conditions: 

Internal material number NOT provided and local EDI configuration 
ZEDITCFG-ZEDIMATNRF = 'R' for redetermine material 
Customer's material number provided 
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Sales area determined 
For logical message ORDCHG, the sales order must exist (using Customer's 
PO number). For DELINS (Scheduling Agreements), both the Scheduling 
Agreement and line item must be determined. 
Audits 

For a new sale order request, or change to an existing order (line item add 
or change where the Customer's material number does not match the 
Customer's material number on the corresponding line item (using Customer's 
line number), the internal material is determined from the Customer Info 
Record using SAP supplied function module 
RV_CUSTOMER__MATERIAL_READ. 

For change to an existing sales document where the Customer's material 
number does not change, the internal material is taken from the matching line 
item on the order. 

Pseudo-Sales Order Workbench Message 

Message ZV 289. Customer provided IBM material & on line &. Manual 
review required. 

Determine Delivering Plant 

Preconditions The delivering plant is determined under the following 
conditions: 

Delivering plant NOT provided 

Internal material determined 
• Sales area determined 

For logical message ORDCHG, the sales order must exist (using 
Customer's PO number). For DELINS (Scheduling Agreements), both the 
Scheduling Agreement and line item must be determined. 
Audits 
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For a new sale order request, or change to an existing order (line item add or 
change where the Customer's material number does not match the Customer's 
material number on the corresponding line item (using Customer's line 
number), the delivering plant is determined from the material's sales view (table 
MVECE, field DWERK). For change to an existing sales document where the 
Customer-s material number does not change, the internal material is taken 
from the matching line item on the order. 
Pseudo-Sales Order Workbench Message 

Message ZV 229. Sales view for material & not found. Process the error 
message and change the Sales area or internal material so that the sales view 
for the material exists. The message must be corrected before the ESO can be 
released from the Workbench. 

Duplicate Sales Order by Line Item and Material 
Preconditions Audit is performed under the following conditions: 

Logical message ORDERS 
• Customer's PO number provided 

Customer's line item provided 

Local EDI configuration set to check for duplicate order 
(ZEDITCFG-ZEDIBSTNK) 
Internal material number determined 
Audits 

Existing sales orders are selected fi'om view M VMVAA using the Customer's 
Sold-to, PO number, and default order type. For each entry in the view, the 
corresponding line items are selected from VB AP. Each line item on the ESO 
is then compared to the entries from VBAP. If a match is found, then the ESO 
is held for the Pseudo-Sales Order Workbench. 
Pseudo-Sales Order Workbench Message 
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Message ZV 243. Duplicate sales order for customer's PO &, line &, and 
material. From the Overview Menu, change the customer's PO, line, or 
material if this is not a duplicate request; otherwise, reject the customer's 
request. 

Validate Line Item and Action Code in Context with Request 
Preconditions 

Audit is performed under the following conditions: 

Customer's line item provided 
• Internal material number determined for logical message ORDCHG and 

DELINS 

Existing sales order found for logical message ORDCHG and DELINS 
Audits 

Each line item on the ESO must be unique. In addition, the foUov^ng matrix is 
used to validate the action code in context with the Customer*s request: 



Logical Message 


Line Item Action Code 
Domains 


Audit 


ORDERS 


'OOr- Add 


See Duplicate Sales 
Order 
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ORDCHG and 


'OOr " Add 


'00 r - Line item and 


DELINS 


'002' - Change 


internal material must 




'003' - Delete 


not exist on sales order 






'002' - Line item and 






internal material must 






exist on sales order 






'003' - Line item and 






internal material must 






exist on sales order 



If any of the audits fail or if a line item '003' delete is requested, then the ESO 
is held for the Pseudo-Sales Order Workbench 
Pseudo-Sales Order Workbench Message 

Message ZV 247. Customer's line & not unique on request. Process the 
error message and change the customer's line item to be unique on the ESO if 
approved by customer; otherwise, reject the customer's request. 

Message ZV 246, Customer's line & and action code & not valid for an 
existing order. Process the error message and change the action code to a valid 
domain. 

Message ZV 245. Customer's line & and action code & not valid for a 
new sales order. Process the error message and change the action code to '00 T 
or reject the customer's request. 

Message ZV 275. Customer's line & and action code & inconsistent for 
an existing sales order. Process the error message and change the line item or 
action code to be consistent or reject the customer's request. 

Message ZV 283. Customer has requested to delete line &, Manual 
review required. 
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Verify That Ship-to is Provided on New Sales Order Request 
Preconditions Audit is performed under the following conditions: 

• Logical message ORDERS 

Request is NOT a reference to a contract (reference to contract 
provided in E1EDK02 '005' or '006* qualifier, field BELNR) 
Audits 

Ship-to party must be provided by the Customer at the header level. The 
header level partner is found in ESO segment E1EDKA2, PARVW = 'WE* in 
field PARTN or LIFNR. If the Ship-to is not provided, then the ESO is held 
for the Pseudo-Sales Order Workbench. 
Pseudo-Sales Order Workbench Message 

Message ZV 226. External partner number & not valid for partner function &. 
Process the error message and choose from the list of EDPAR entries or 
fastpath to EDPAR maintenance (trx VOED -> Partner -> Application -> 
Conversion. The Ship-to must be provided before the ESO can be released 
from the Workbench. 

Verify ESO in Context as a Sales Document 
Preconditions 

Audit is performed under the following conditions: 

• Sales Area determined 
Internal material determined 
Delivery plant determined 

Audits 

This audit ensures that the combination of key data elements are valid for this 
request. The following audits of this nature are performed: 

Valid Sales Area (VBAP-VKORG, VTWEG, SPART) exists in TVTA 
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Valid Sales Area by Customer (VB AP-VKORG, TVTA-VTWEG, 
SPART) exists in KNVV 

• Internal material exist in material master MARA and not flagged for 
. deletion 

• Internal material exist in sales view MVKE and not flagged for deletion 
Check for Restricted Material using SAP's supplied function 
RV_Material_Status_Check 

Check for Excluded / Listed Material using SAP's supplied function 
'Product_List_Exclusion' 

Valid delivering plant for Sales Area (VBAP-VKORG, VTWEG) 
exists in TVKWZ 

Internal material exist in delivering plant MARC and not flagged for 
deletion 

Pseudo-Sales Order Workbench Message 

Message ZV 227. Invalid Sales Area & & &. Process the error 
message and enter a valid Sales Area. The Sales Area must be valid before the 
ESO can be released from the Workbench. 

Message ZV 378. Sales Area & & & not defined for customer &. 
Process the error message and enter a valid Sales Area for customer. The Sales 
Area must be corrected before the ESO can be released from the Workbench. 

Message ZV 234. Material & not found for flagged for deletion. 
Process the error message and change the material or reject the customer's 
request. 

Message ZV 235. Material & is restricted for use. Process the error 
message and change the material or reject the customer's request. 

Message ZV 288. Material & has been excluded. Process the error 
message and change the material or reject the customer's request. 
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Message ZV 289. Material & is not listed and therefore, not allowed. 
Process the error message and change the material or reject the customer's 
request. 

Message ZV 23 1 . Delivering plant & not valid for Sales Area & &. 
Process the error message and change the delivering plant, sales area or 
material or reject the customer's request. 

Adjust Customer's Dock Date with Transit Time 

Preconditions The offset is performed under the following conditions: 

No PROFIT/ ATP Commits on ESO (Commits present implies ESO is 
from the OEMLS Interface Logical message ORDERS and code 9BD) 

• Customer's line item provided 

• Local EDI configuration set to Customer's dock date 
(ZEDITCFG-ZEDIDATQAL = 'D') 

• Internal material number determined 

• Delivering plant determined 
Ship-to determined 

First from line level on ESO (ElEDPAl) 

Second from header level on ESO (ElEDKAI) 

Third, if logical message ORDCHG or DELINS, then from 

sales document 

Audits 

The customer's request dock date is offset the transit time for the Ship-to, 
delivering plant, and material. The transit time number of days is maintained 
using trx ZEDI -> MasterData -> Transit Time Data. The transit times can be 
maintained (and determined in this order) at the following levels: 

Delivering plant, material. Ship-to 

Delivering plant. Ship-to 
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Each request date on the ESO is adjusted with the transit time offset. Request 
date in SAP always represents IBM ship date. 

Adjust Minimum Order Quantity (MOQ) and Ship Pack Quantity (SPQ) 
Preconditions Adjustment is performed under the following conditions: 
• Sales Area determined 

Internal material determined 

Line item action code NOT = '003' (delete) 

Schedule lines added to ESO by the Order interceptor when bringing 
forward Open JIT schedules are NOT subject to MOQ/SPQ checks 

Audits 

Before MOQ and SPQ checks are performed, the request quantity at 
the line item level is adjusted to match the sum of all the delivery schedule 
quantities. The minimum order quantity and ship pack quantity for a material is 
held at the sales view MVKE, fields AUMNG and SCMG respectively. 

MOQ checks are carried out at the material level (line items for the 
same material are summed). If the request is out of MOQ, then the following 
domain values from the local EDI configuration table ZEDITCFG-MOQ 
determines how the quantity is adjusted. This rule can be configured down to 
the material level: 



Domain Value 


Action 


' ' - Accept as is 


Request quantity NOT adjusted 


'M' - Manual review 


Held for Pseudo-Sales Order 
Workbench for manual review 
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•U' - Round up 


Request quantity for last line item 




for material is rounded up to be in 




MOQ 



SPQ checks are carried out for each schedule line. If the request is out of SPQ, 
then the following domain values from the local EDI configuration table 
ZEDITCFG-SPQ determines how the quantity is adjusted. This rule can be 
configured down to the material level: 



Domain Value 


Action 


' ' - Accept as is 


Request quantity NOT adjusted 


*M' - Manual review 


Held for Pseudo-Sales Order 
Workbench for manual review 


•U' - Round up 


Request quantity rounded up to be in 
SPQ 


'D' - Round down 


Request quantity rounded down to 
be in SPQ 



Pseudo-Sales Order Workbench Message 

Message ZV 232. The requested quantity is out of SPQ for line & and 
schedule &. Process the warning message and change the request quantity to 
be in SPQ or accept as is. 

Message ZV 230. The requested quantity is out of MOQ for line &. 
Process the warning message and change the request quantity to be within 
MOQ or accept as is. 
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Audits Specific by Order Type 

Preconditions 

None 

Audits 

The following audits are performed on Rush Orders (SO order type): 

If local EDI configuration ZEDITCFG-ZEDIREFBPO is set to true 
and a reference to a contract is not provided (E1EDK02, qualifiers *005* 
or '006, field BELNR, then manual review is required. 
If request date < system date, then manual review is required. 

Pseudo-Sales Order Workbench Message 

Message ZV 366. Rush order requires reference to a contract. Manual 
review required. 

Message ZV 392. Request date is in the past. Manual review required. 
Verify Sales Document is NOT in ATP Pipeline from Prior ESO 
Preconditions 

Audit is performed under the following conditions: 
Logical message ORDCHG or DELINS 
Existing sales order found 

Audits 

If the request is to change an existing sales document, then a check is made to 
see if the sales document is being processed by PROFIT/ATP (ATP results 
from prior ESO not applied to order). The ESO to ATP Customer Order table 
ZATPGEN is used for this audit. If an entry is found, then the ESO is held for 
the Pseudo-Sales Order Workbench, 
Pseudo-Sales Order Workbench Message 

Message ZV 38 1 . & is being processed by PROFIT/ATP ( ESO &), try again 
later. 

BU999-021 



52 

Validate Logical Message Code for Change Order 
Preconditions Audit is performed under the following conditions: 
Logical message ORDCHG 

Audits 

The following logical message codes are not supported by the Order 
interceptor: 

BPO Change to a Contract 
Pseudo-Sales Order Workbench Message 

Message ZV 382. Change to a contract is not supported. The ESO must be 
marked complete in the Workbench and can not be posted to the application. 

Validate if Change is Within Frozen Zone Period 
Preconditions Audit is performed under the following conditions: 
Logical message ORDCHG 
Existing sales order found 
Line item action code indicates change or delete 

Audits 

If the Customer requests a change to either the date, quantity, or 
material, then manual review is required. If the change is occurring within the 
frozen zone period for the material, then the manual review message will also 
note this condition. The request date and quantity are compared to the order*s 
commit date and quantity if the order is committed; otherwise, the request date 
and quantity are compared to the order's request date and quantity. 

The frozen zone number of days for a material is defined in the local 
EDI configuration table ZEDITCFG- ZFROZONE. If the material is not 
configured, then the frozen zone is taken from the Customer / logical message 
level. The change is considered to be within the frozen zone if the requested 
date < (system date + frozen zone days). 
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Pseudo-Sales Order Workbench Message 

Message ZV 343. Review changes within frozen zone for & and 
customer's line item &. Manual review required. 

Message ZV 35 1 . Review changes for & and customer's line item &. 
Manual review required. 

Apply Shipments to Changing a Sales Order 
Preconditions Audit is performed under the following conditions: 

Logical message ORDCHG 

Existing sales order found 

Line item action code indicates change 

Audits 

Shipments are applied on the ESO in segment E1EDP20 field AMENG and are 
subsequently available for display in the Workbench. In addition, the delta 
between the request quantity and ship quantity is sent to PROFIT/ATP for 
commit (and not the request quantity). The shipped quantity for a schedule line 
is derived from tables VBEP-WMENG minus VBBE-OMENG (request 
quantity - open quantity = ship quantity). The following audits are also 
performed: 

• Schedule line still open 

Requested quantity from ESO > shipped quantity 
Pseudo-Sales Order Workbench Message 

Message ZV 380. Schedule line is no longer open. The ESO must be 
marked complete in the Workbench and can not be posted to the application. 

Message ZV 377. Item &: requested quantity & less than delivered 
quantity &. The ESO must be marked complete in the Workbench and can not 
be posted to the application. 

Message ZV 277. Customer's line item & has been shipped. The 
request must be applied manually (Order interceptor does not support shipment 
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consumption logic with multiple request dates). The ESO must be marked 
complete in the Workbench and can not be posted to the application. 

Audits Specific to Create Sales Order with Reference to a Contract 
Preconditions Audit is performed under the following conditions: 
Logical message ORDERS 

Reference to contract provided on ESO ( E1EDK02 with qualifier '005 
or '006' field BELN) 

Audits 

The following audits are performed when creating a sales order with reference 
to a contract: 

If reference to contract provided (qualifier '006'), contract must exist 
If reference to contract not provided, then determine contract fi-om 
referenced contract PO (qualifier '005') using view M_VMVAA 
Ship-to is taken from referenced contract if not provided on ESO 
Ship-to on ESO if provided must match Ship-to on referenced contract 
All materials on ESO are listed on the referenced contract 
If request quantity + prior pulls (using VBFA-RFMNG sales document 
flow) exceeds open quantity on contract, then manual review required 

Pseudo-Sales Order Workbench Message 

Message ZV 364. Contract not found using customer's contract PO. 

Process the error message and either correct the referenced PO or reject the 

customer's request. 

Message ZV 365. No unique contract could be determined using 

customer's contract PO. Process the error message and choose the contract 

from the list of contracts matching the referenced PO. 
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Message ZV 347. Reference contract & not found for customer 
Process the error message and either correct the referenced contract or reject 
the customer's request. 

Message ZV 348. Material & not found on referenced contract. 
Process the error message and change the material number or reject the 
customer's request. 

Message ZV 371 . Ship-to on ESO does not match Ship-to on 
referenced contract. Process the error message and change the Ship-to on the 
ESO or reject the customer's request. 

Message ZV 367. Request quantity exceeds open quantity on contract. 
Manual review required. 

Audits Specific to Creating a Contract 
Preconditions 

Audit is performed under the following conditions: 
Logical message ORDERS and code BPO 
Internal material determined 

Audits 

The following audits are performed when creating a contract: 

Same material can only be on contract one time (no duplicates) 
Pseudo-Sales Order Workbench Message 
Message ZV 383. Material & not unique on contract request. 

Audits Speciflc to Creating a Scheduling Agreement Release 
Preconditions 

Audit is performed under the following conditions: 
Logical message DELINS 
Existing Scheduling Agreement found 
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Line item on Scheduling Agreement determined 

Dates converted from dock to ship date (see Adjust Customer's Dock 

Date with Transit Time) 

Audit 

The following fields are added to the ESO if not provided: 



Segment-Field 


Description 


Rule 


EIEDK09-LABNK 


Customer's number for 
fds/jit release 


Generate next number 
using 

'Numbcr_Gct_Ncxt', 
object ZFDSNO or 
ZJITNO, range'Or 


E1EDK09-ABNRA 


Customer's number for 
previous FDS/JIT 
processed 


FromVBLB where 
ABART=TforFDSor 
*2' for JIT andABRLI 
= 0 (current version), 
field LABNK 



If the release is JIT (EIEDPIO-SCREL = '02'), then the following addition 
audits are performed: 

Verify that an FDS (Forecast Delivery Schedule) exist in table VBLB 

where ABART = ' 1' and ABRLI = O 

If mode is append (EIEDPIO-LABKY = *!'), then any open delivery 
schedules are brought forward and appended as delivery schedules on the ESO 
(segment E1EDP16). This audit is performed only once. Open schedules are 
determined by comparing tables VBEP and VBBE. If the schedule is still open 
(entry is VBBE), then the delivery schedule is brought forward. In addition, 
any shipments against the delivery schedule is also applied to the ESO 
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(E1EDP16-FZABR) and is subsequently available for display in the 
Workbench. The delta between the request quantity and ship quantity is sent to 
PROFIT/ ATP for commit. The shipped quantity for a delivery schedule is 
derived from VBEP-WMENG minus VBBE-OMENG. 



The following fields on the ESO are redetermined: 



Segment-Field 


Description 


Rule 


EIEDKIO-ABRAB 


Release valid-from date 


Earlies request date 
(E1EDP16-EDATUB) 
on ESO including those 
brought forward for 
JIT 


EIEDKIO-ABRBI 


Release valid-to date 


Latest request date 
(E1EDP16-EDATUB) 
on ESO including those 
brought forward for 
JIT 


ElEDK 10- ABHOR 


JIT valid-to date 


If JIT release, then set 
toElEDKlO-ABRBI 



Finally, the validity periods (valid-from/to dates) are compared to those on the 
Scheduling Agreement (VBAK-GUEBG valid-from and VB AK-GUEEN 
valid-to). If either of the dates fall outside the horizon, then manual review is 
required. 

Pseudo-Sales Order Workbench Message 

Message ZV 372. No delivery schedules were provided on the ESO. 
Reject the Customer's request, 
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Message ZV 369. Valid from date outside the validity period on 
Scheduling Agreement. Manual review required. 

Message ZV 370. Valid to date outside the validity period on 
Scheduling Agreement. Manual review required. 

Check if Configured for Manual Review 
Preconditions 

Audit is performed under the following conditions: 

Local EDI configuration set to manual review 
(ZEDITCFG-ZMANREVIEW = or '3') 
Audits 

The local EDI configuration field ZEDITCFG-ZMANREVIW determines if an 
ESQ is held in the Pseudo-Sales Order Workbench for manual review. The rule 
can be configured down to the material level. The domains are: 

• * * No manual review required 

* 1' Hold for Pseudo-Sales Order Workbench 

• '2' Block Sales Order and Proposing Acknowledgment 

'3* Both Hold for Pseudo-Sales Order Workbench and Block Sales 
Order and Proposing Acknowledgment 

Pseudo-Sales Order Workbench Message 
Message ZV 225. Manual review required. 

Apply Updates to ESO 
Preconditions 

The ESO is updated if any updates are made by the Order interceptor. 
Audits 
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The Order interceptor keeps internal tables of fields and segments that need to 
be updated back on the ESO. This includes new segments, changes or deletes 
to existing segments. The updates are applied to the ESO data segment in table 
ESO Data (405)after all the audits are performed and prior to the ESO being 
passed to subsequent processes, such as Pseudo-Sales Order Workbench or the 
Pre and Post ATP processes. Before the updates are applied, the original ESO 
is copied to a new ESO with the status of 70'. Any change to the ESO is noted 
in the status segment ESO Status (406)with a status ofW\ This gives a full 
audit trail of changes made by the Order interceptor, such as if the Sales area, 
internal material and/or delivering plant was added, and so on. Table EDSYN 
is used during the update process to ensure proper syntax of the ESO. 
Function module Z_IDOC_Update_Data_Resequence is used to perform the 
actual table update. 

Hold ESO for Pseudo-Sales Order Workbench 
Preconditions 

The ESO is held in the Pseudo-Sales Order Workbench under the following 
conditions: 

Audit fails or manual review required 

Header is NOT rejected (If rejected, already in Workbench and ready 
to release) 

• All line items are NOT rejected (If rejected, already in Workbench and 
ready to release) 

Input mode is NOT from Pseudo-Sales Order Workbench (Implies 
already held in Workbench) 

Audits 

Before any audits are performed, the Order interceptor builds an 
internal 
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table of all the error messages that have been reviewed in the Pseudo-Sales 
Order Workbench for the given ESO. Messages are communicated by the 
Order interceptor to the Pseudo-Sales Order Workbench via table 
ZEDIWMSG. Messages requiring manual review (as opposed to correction) 
are flagged as reviewed by the Pseudo-Sales Order Workbench when the 
appropriate action is taken. 

The Order interceptor records all error and manual review messages in 
an internal table which is analyzed to see if the ESO should be held for the 
Pseudo-Sales Order Workbench. All entries in the communication table 
ZEDIWMSG owned by the Order interceptor (some messages are also owned 
by the Post-ATP and Call Transaction Processes) are deleted and rebuilt from 
the internal table. As the entries are added to ZEDIWMSG, the "reviewed" 
internal table is cross-referenced and if a match is found, then the message is 
flagged as already reviewed. By using this technique, the Order interceptor 
always remembers which messages were reviewed by the User. If the header 
has been rejected, then no messages are recorded in the Workbench. Likewise, 
messages specific to a line item are not recorded if the line item has been 
rejected. This way, the User can Release the ESO even though an error 
condition may still exist (which requires a header or line level reject). 

Each entry added to ZEDIWMSG is also added to the ESO's status 
table ESO Status (406)with status of *Z T (Message from Order interceptor) 
provided the message has not already been reviewed. The ESO status is then 
set to 'Zl\ held for Pseudo-Sales Order Workbench (unless already 'Z2'). 

If the Input Mode is not from the Pseudo-Sales Order Workbench 
(implies Work Item already exists), a Pseudo-Sales Order Workbench Work 
Item is created using function module 'Z_Worktlow_Error_Create'. The Work 
Item text consists of order type and action, delivering plant, internal material, 
Pseudo-Sales Order and Customer name. 
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Reject and Acknowledge ESO without Posting to Application 
Preconditions The ESO is rejected and acknowledged under the following 
conditions: 

• Header is rejected in the Pseudo-Sales Order Workbench (segment 
ZIEDKOl, field ZREJCODE non blank) 

• All line items are rejected in the Pseudo-Sales Order Workbench 
(segment ElEDPOl, field ABGRU non blank ) 

• Input mode is NOT fi*om Pseudo-Sales Order Workbench (Implies 
already held in Workbench) 

Audits 

If the header is rejected or all line items are rejected fi'om the Pseudo-Sales 
Order Workbench, then an outbound acknowledgment ESO is created using 
function module *Z_ACK REJ PO*. This ESO contains the customer's original 
request along with reason codes and description of why the request was 
rejected. The inbound ESO is then marked complete (status set to 'Z6') and not 
posted to the application, 
Pseudo-Sales Order Workbench Message 

Error messages from *Z_ACK_REJ_PO' are recorded for the Pseudo-Sales 
Order Workbench. 

Pre-ATP Processing 
Preconditions 

The ESO is sent to Pre-ATP (fiinction module 'Z IDOC INPUT^PRE ATP') 
under the following conditions: 

• No error or manual review message (unreviewed) exist for ESO 
ESO is not rejected or marked complete or routed to OEMLS (111) 

• Input method not from Customer PO Workbench (607) 
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• Order type defined in table ZATPO Note: No check is made to see if 
material is an ATP part 

Audits 

The following functions are performed before the request is sent to 

ZJDOC_INPUT__PRE_ATP: 

If the logical message is DELINS (Scheduling Agreement) and request 
is a JIT release, then the open FDS is added to the delivery schedule 
internal table that is passed to ATP; likewise, if the request is a FDS 
release, then the open JIT is added to the delivery schedule internal 
table. Notice that these schedules are not applied to the ESO. 

Note: PROFIT/ATP requires both the FDS and JIT schedules in order to 

perform its ATP logic 

The following structures and internal tables are then constructed from 
the ESO and existing sales order: 

• Header structure XVBAK representing header data on ESO 
Header structure YVBAK representing header data on existing order 
Line item table XVBAP representing line items on ESO 

Line item table YVB AP representing line items on existing order 
Delivery schedule table XVBEP representing deliveries on ESO 
Delivery schedule table YVBEP representing deliveries on existing 
order 

Partner table XVBPA representing partner functions on ESO (both 
header and line items) 

• Partner table YVBAP representing partner functions on existing order 

• Delivery schedule commit table XVBEP2 representing commits on 
ESO supplied from external interface such as OEMLS (111) 
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Extra details: 

• The order number field VBELN in the tables and structures 
listed above is determined as follows: 

For logical message ORDERS and Input Method from 
the WEB -> ^WB + last 8 digits of ESO number 
For logical message ORDERS and all other Input 
Methods -> 'ED + last 8 digits of ESO Number 
For logical message ORDCHG or DELINS -> use 
existing order number 

Line items rejected in the Customer PO Workbench (and entire 

request not rejected) are NOT sent to ATP 

Line item canceled by Customer are denoted with *D' in field 

XVBEP-UPDKZ 

• Delivery schedule types are denoted in field XVBEP-ABART 
• ' ' Normal 

'V FDS 
*2' JIT 



Table ZATPGEN is updated to cross-reference the ESO number with 
the VBELN number sent to ATP. The key values are: 

ZATTRIB = 'ZEDIATP' 

ZP ARAM = Order Number 

ZRECID= 123456 

ZREC VALUE = ESO Number 



The request is then sent to Pre-ATP (function module 
ZJDOC_INPUT_PRE_ATP (313)) which populates the ATP / SAP Interface 
table ZATPDEM with the information supplied in the API (see structures and 
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tables above) and interfaces to ATP as instructed in the API via MQSeries. 
Parameter TRIGGER ATP (V send to ATP) controls if the request is to be 
sent to ATP. This is the case for all ESOs except when commits are present on 
the ESO (from OEMLS (II 1), for example). Parameter RESEND_COMMIT 
is only used when an ESO is rejected by Customer and the request has been 
committed by ATP and the logical message is ORDCHG or DELINS. When 
RESEND_COMMIT V, then the commits on the existing order is resent to 
ATP to replace the latest commits vs RESEND COMMIT = ' ' which means 
requesting a commit. Parameter TRIGGER ZMOM 103 tells ATP to raise an 
event to trigger the Restart ESOs in Z4 Status (ZMOMI03) module (319) 
upon returning the ATP results. If the link to ATP is not responding in a timely 
manner (currently set to 60 seconds), the Pre-ATP function is re-executed with 
the trigger set to V. The ESO's status is set to *Z4* and processing of the ESO 
is suspended until the Restart ESOs in Z4 Status (ZMOMI03) module (319) is 
triggered. 

After Pre-ATP is performed, the interface table ZATPDEM is polled 
every 3 seconds to see if the results from ATP have been posted. If all delivery 
schedules on the ESO have a response, then Post- ATP 
(Z IDOCJNPUT POST ATP) is performed. The loop is repeated until all 
delivery schedules have a response or time limit exceeded (up to 20 times or 1 
minute elapsed time). If the time limit exceeded, then the Pre-ATP function is 
re-executed with TRIGGER_ZMOMI03 set to V. When the Restart ESOs in 
Z4 Status ZMOM 103 module 319 is triggered, then Post- ATP is performed to 
pick back up the processing of the ESO. 
Pseudo-Sales Order Workbench Message 

Error messages from the ZJDOC_INPUT_PRE_ATP module (313) are 
recorded for the Customer PO Workbench module (607). 
Pseudo-Sales Order Workbench Description 
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The Pseudo-Sales Order Workbench 106 is a tool to allow the 
Customer Service Representative (CSR) the ability to review and/or change a 
customer's inbound purchase order before it is processed into an SAP Sales 
Order. One of the main advantages is that the customer's order request is 
presented in a pseudo-sales order. There are currently four supported scenarios 
by the workbench and order interceptor: 

1 . Create and changes of SAP Sales Orders (ie, VAO 1 , VA02) 

2. Create and changes of SAP Sales Orders with reference to a 
SAP Contract (ie VAOl, VA02) 

3. Changes of SAP Scheduling Agreement Outline Agreement (ie, 
VA32) 

4. Create SAP Contract Agreement Outline Agreement (i.e., 
VA41) 

There is some initial configuration to be done prior to using the 
workbench which is not cover in this document such as to configure a specific 
customer to always manually review their orders, etc. Although, the CSR has 
the capability to branch to selected configuration processes fi'om the 
workbench which will be covered in detail later in this document. The order 
interceptor documentation above explains the customer specific rules and 
configuration. 

The CSR can also reject the entire customer order or only reject 
specific line item(s) of the order. There is also functionality to "accept as is" if 
the quantities are out of MOQ or SPQ. One of the major functions of the 
workbench is to review and/or correct all of the error messages associated with 
an inbound order. All the corrections will be made to the ESO data which is 
the input to the SAP Sales Order create/change processes. Once the data has 
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been changed, it must be saved before proceeding to the next screen and/or 
returning back to the previous screen. The following list represents the type of 
data fields that are allowed to be modified: 
Sales Area Data 

• Sales Organization, Distribution Channel, Division 

• Sales Group, Sales Office 

• External Partner Number (ie, ship-to, bill-to, etc) 
IBM Internal/SAP Material Number 

• Delivery Plant 

• Requested Date and Date Format 
Requested Time 

Requested Quantity 

Scheduling Agreement Current & Previous release numbers 
Scheduling Agreement search criteria 

Other data fields that may be corrected due to an error will include the 
customer's PO number, the customer's PO Line Item number, the ESO Action 
Code for the line item, and others as the workbench grows with more fianction. 

Once all errors have been corrected/re viewed, you then "Release to 
Sales Doc" for follow-on processing to create/change a SAP Sales Order. If 
for some reason the SAP Sales Order create/change fails, it will appear in the 
workbench with a message "Call transaction VAOl failed.... Press HELP(?) for 
instructions". At that time the CSR should following the instruction(s) on how 
to determine the error causing the transaction to fail. 

Figure 6 shows a preferred embodiment of a screen from the 
workbench to show the "pseudo-sales order" view. 

Pseudo-Sales Order (Prc-Sales Order) Overview Screen 
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As shown in Figure 7, the customer PO (pre-sales order) overview 
screen contains all of the header and line item data from the inbound customer 
PO. The screen is broken into data groupings to assist the CSR in determining 
the sales area data, and key customer data such as the sold-to customer 
number, the customer's PO number, the customer PO date, the type of 
transaction (850 new or 860 change), and the existing SAP Sales Order 
number. Next are all of the items which are scrollable to page down and up. 

Depending on the error message or if you hit the "Overview" 
pushbotton, certain fields are modifiable. If the date or quantity on the item 
level are changed and the inbound ESO had one delivery schedule, the data on 
the delivery schedule would also change. If there were multiple delivery 
schedules, the item level date and quantity fields will NOT be modifiable. 

If a user chose to reject the entire order, the customer PO (pre-sales 
order) overview screen is where the reject reason code would be entered. 

If PROFIT Commit data is present, the CSR can not change any data 
due to the dates and quantities are already committed for that plant. 



Overview Menu Functions 



FUNCTION 


FUNCTION DESCRIPTION 


Save 


Once you have changed data, you 




have the option of saving it on the 




inbound ESO before leaving this 




screen. If you save data on any 




screen, "Data SAVED on ESO 




xxxxxxxxxxxxxxxx" message will be 




received, where the x's are the actual 




ESO number. 
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Partner 


Allows the CSR to view all header 
and item level partner segments of 
the inbound ESO, If needed, changes 
can be made and saved. 


PROFIT Commits 


Allows the CSR to view the 
PROFIT committed dates and 
quantities as well as the requested 
dates and quantities. Anytime 
PROriT commit data is present on 
the order, no fields are allowed to 
change. 


OEMLS Data 


Allows the CSR to view the 
OEMLS data that was on the ESO. 
This data includes the customer PO 
number, IPR number, the IBM 
supplier location code, and the IBM 
ship to location code. 
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Delivery Schedules 


Allows the CSR to view/change the 
dates and quantities at the delivery 
schedule level. There could be 
multiple delivery schedules per item. 
Other key data is also displayed at 
this level such as the MOQ and SPQ 
quantities for that material. You may 
use the checkbox to viev/ that 
specific item's delivery schedules or 
simply hit the Delivery Schedules 
pushbotton to page through each 
one. 


[Vlnlerials on EDI Trx 


A popup window displays all the 
material number(s) that existed on 
the inbound EDI transaction. It also 
shows what kind of material number 
it is in terms of customer's material 
number, Vendor's material number, 
changeable/catalog material number, 
elc. 
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EDI Local Config 


This functions allows the CSR to 




branch to the local EDI 




configuration screens to add/change 




configuration data. This same set of 




options may also be invoked by 




issuing transaction ZEDI. The 




options branch to the specific config 




tables/data: 




By Cusf/Msg/Material - config 




data keyed by sold-to customer 




number, logical message (such as 




ORDERS and ORDCHG), message 




code (indicating specific internal 




customer like Ireland), and/or 




material number This is to configure 




each cus!omer*s PO to be held in the 




workbench based on specific 




indicators such as manual review. 




out of MOQ/SPQ, allow line item 




rejects, etc. 




By Customer - config data keyed by 




sold-to customer to determine 




inbound transaction processing rules 




such as use the customer's dock date 




or ship date as well as to use the 




customer's material number or the 




IBM catalog number. 
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IntoExt Sold-To - config data 
keyed by customer number to 
determine the internal customer 
number from external, ISA, or GS 
numbers as well as the specific 
partner function code. 
Header Reject Codes - config data 
keyed by reject reason code for 
specific header level reject reason 
descriptions 


Sales Order Display 


Allows the CSR to branch to native 
SAP Sales Order Display processing 
via transaction VA03, If the existing 
Sales Order is known, it will 
automatically use that sales order 
number. 


Sched Agreement Disp 


Allows the CSR to branch to native 
SAP scheduling Agreement Outline 
Display processing via transaction 
VA33 . If the existing Scheduling 
Agreement is known, it will 
automatically use that sched 
agreement number. 


Contract Agrmnt Disp 


Allows the CSR to branch to native 
SAP Contract Agreement Outline 
Display processing via transaction 
VA43. 
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Back, Exit, Cancel 


Returns you to the previous screen. 




If you have modified any data and 




have not saved it, it will provide you 




with a "Updates Pending" pop-up 




menu asking to "go back and SAVE 




the data?". You may reply YES to 




return to the screen where the 




changes were made for you to issue 




a SAVE; reply NO or CANCEL to 




return to the previous screen without 




saving any data. 



Psetido-Sales Order (Pre-Sales Order) Delivery Schedules Screen 

This screen, as shown in Figure 7, allows the CSR to review/change all 
the delivery schedules for a line item. Both the date and quantity are modifiable 
fields. If there are multiple delivery schedules, these will be scrollable via the 
page up and page down. Please note that if you change one or more of the 
delivery schedules, the workbench will automatically accumulate the total to be 
updated on the item quantity field. The CSR will be notified via an information 
message if this occurs. This screen also allows the CSR to correct or accept 
quantities that are out of MOQ or SPQ. Both the "SAVE" and "SAVE As Is" 
works the same way by saving whatever value currently in the quantity field. 



Delivery Schedules Functions 



FUNCTION 



FUNCTION DESCRIPTION 
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Save ofSAVE^AsJS 


Once you have changed data, you 






have the option of saving it on the 






inbound ESO before leaving this 






screen. If you save data on any 






screen, you should receive a 






message "Data SAVED on ESO 






xxxxxxxxxxxxxxxx", where the x*s 






are ihe actual ESO number. 




Next Item 


If you did not select a single item*s 






delivery schedule to be displayed. 






the pushbutton will page through 






each line item available (or that 


W 




contains a delivery schedule) to 


yj 




display the delivery schedules data 






for review/change. 




PROFIT Commits 


Allows the CSR to view the 






PROFIT committed dates and 






quantities as well as the requested 






dates and quantities. Anytime 






PROFIT commit data is present on 






the order, no fields are allowed to 






change. 
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Sales Order Display 


Allows the CSR to branch to native 






SAP Sales Order Display processing 






via transaction VA03. If the existing 






Sales Order is known, it will 






automatically use that sales order 






number. 




Material Master Disp 


Branches to the native SAP Material 






Master Display transaction MM03. 






You must select the item for which 






material you want to display via the 






checkbox. 


s 


Customer Master Disp 


Branches to the native SAP 






Customer Master Display 






transaction VD03, It will 






automatically use the sold-to 


w 




customer number, and sales area 






data for the VD03 transaction. 




Master Sales View 


Branches to the native SAP Material 






Master Display transaction MM03 






and chooses the sales view data 






automatically. Here the CSR may 






sec all the sales view data such as 






MOQ SPQ values. 
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Back, Exit, Cancel 


Returns you to the previous screen. 




If you have modified any data and 




have not saved it, it will provide you 




with a "Updates Pending" pop-up 




menu asking to "go back and SAVE 




the data?". You may reply YES to 




return to the screen where the 




changes were made for you to issue 




a SAVE; reply NO or CANCEL to 




return to the previous screen without 




saving any data. 



Reject Acknowledgment Flow and Description 

The reject acknowledgment process shown in Figure 4 is now 
explained in greater detail. The reject acknowledgment system 107 takes an 
inbound ESO and creates a corresponding ESO containing reject codes and 
appropriate values. It can be used to reject incoming ESO's with types of sales 
orders (850), sales order change (860), or forecasts (830). 

An inbound ESO 401 is rejected from the sales order interceptor 
workbench by entering a reject code for the ESO at a header level. The values 
that are sent in the reject acknowledgment can be based on the inbound ESO 
values for new sales orders or based on existing data in SAP for rejected 
change orders. This configuration is set in table ZEDITCFG (field 
ZREJMETHOD). If the outbound ESO is built based on taking the original 
values, a reject segment (ZlEDKOl) containing the reject code and description 
is taken from the edited ESO and appended to the outbound reject 
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acknowledgment ESO. The final step is to update the ESO reconciliation table 
(ZEDIACKR) for the incoming ESO with the outbound ESO number. 

The reject acknowledgment system allows the response to the customer 
without sending the customer's order request to the order processing system. 

While the invention has been described in terms of a single preferred 
embodiment, those skilled in the art will recognize that the invention can be 
practiced with modification within the spirit and scope of the appended claims. 
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CLAIMS 



Having thus described our invention, what we claim as new and desire to 
secure by Letters Patent is as follows: 



1 1 . A system for pre-processing orders before they are transmitted to an order 

2 processing system, comprising: 

3 an order interceptor receiving and processing electronic sales order 

4 data; 

5 an interface system receiving the electronic sales order data from the 

6 order interceptor and performing an availability check, wherein the availability 

7 check determines the portions of the electronic sales order data that can be 

8 satisfied; and 

9 means for transmitting at least a portion of the electronic sales order 
1 0 data to the order processing system. 

1 2, I he system of claim 1, wherein the order interceptor translates the 

2 electronic sales order data to an internal format of the order interceptor, 

3 determines if an availability check is required, transmits at least a portion of the 

4 electronic sales order data, determines if there are any processing problems 

5 associated with the electronic sales order data, and processes the electronic 

6 sales order data in accordance with business rules. 

1 3. The system of claim 2, wherein the order interceptor comprises: 

2 means for receiving the electronic sales order data; 

3 means for translating the electronic sales order data to an internal 

4 format of the order interceptor; 

5 means for determining if an availability check is required; 
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6 means for transmitting at least a portion of the electronic sales order 

7 data; 

8 means for determining if there arc any processing problems associated 

9 with the electronic sales order data; and 

1 0 means for processing the electronic sales order data in accordance with 

1 1 business rules. 



1 4, The system of claim 1, further comprising a workbench receiving electronic 

2 sales order data that contains errors or is incomplete. 

1 5. The system of claim 4, wherein the workbench receives and displays 

2 electronic sales order data that contains errors or is incomplete, displays error 

3 messages associated with the electronic sales order data, and enables a user to 

4 edit, correct, and update at least one database containing the electronic sales 

5 order data. 



1 6. The system of claim 5, wherein the workbench comprises: 

2 a) means for receiving and displaying electronic sales order data that 

3 contains errors or is incomplete; 

4 b) means for displaying error messages associated with the electronic 

5 sales order data of step a); and 

6 c) means for correcting, editing, and updating the at least one database 

7 containing electronic sales order data. 

1 7. The system of claim 5, wherein the workbench further displays a status of 

2 the electronic sales order data, determines if configuration rules are satisfied, 

3 and provides an indication to the order interceptor that at least a portion of the 

4 electronic sales order data is rejected. 
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1 8. The system of claim 7, wherein the workbench further comprises: 

2 means for displaying the status of the electronic sales order data; 

3 means for determining if the configuration rules are satisfied; and 

4 means for indicating to the order interceptor that at least a portion of 

5 the electronic order data is rejected. 

1 9. The system of claim 1 , further comprising a reject acknowledgment system 

2 receiving an indication from the order interceptor that at least a portion of the 

3 electronic sales order data has been rejected. 

1 10. The system of claim 9, wherein the reject acknowledgment system updates 

2 at least one database to indicate the portions of the electronic order data that 

3 have been rejected. 

1 11. The system of claim 9, wherein the reject acknowledgment system 

2 comprises: 

3 means for receiving an indication from the order interceptor that at 

4 least a portion of the electronic sales order data is rejected; and 

5 means for updating the at least one database to indicate the portions of 

6 the electronic order data that have been rejected. 

1 1 2. The system of claim 10, wherein the reject acknowledgment system further 

2 determines if the electronic sales order data was received via a transmission 

3 from the World Wide Web, and updates the at least one database in either an 

4 ESO format or an SAP format. 
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13. The system of claim 12, wherein the reject acknowledgment system further 
comprises: 

means for determining if the electronic sales order data was received 
via a transmission from the World Wide Web; and 

means for updating the at least one database in either an ESO format or 
an SAP format. 

14. The system of claim 1, wherein the order interceptor receives the 
electronic sales order data in a standard Electronic Data Interchange (EDI) 
format. 

1 5. The order interceptor system of claim 1, wherein the system is an SAP 
system. 

1 6. A computer implemented method of processing electronic sales order data 
before it is transmitted to an order processing system, comprising the steps of: 

receiving electronic sales order data; 

translating the electronic sales order data to an internal format; 

transmitting the electronic sales order data to an interface system^ 
wherein the interface system performs an availability check to determine what 
portion of the electronic sales order data that can be satisfied; and 

if the availability check indication is to transmit, transmitting the 
designated portions of the internal format data to the order processing system. 

17. The computer implemented method of claim 16, further comprising the 
steps of 

a) processing the electronic sales order data in accordance with 
business rules; 
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b) determining if there are any processing problems associated with the 
electronic sales order data; and 

c) if there arc processing problems in step b), transmitting an electronic 
message to at least one user indicating that the electronic sales order data 
contains errors or is incomplete, 

1 8. The computer implemented method of claim 1 7, further comprising the 
steps of: 

enabling a user to correct the electronic sales order data; and 
transmitting the corrected electronic sales order data to the order 
processing system. 

19. The computer implemented method of claim 16, further comprising the 
steps of 

rejecting the electronic sales order data thai cannot be filled; and 
updating at least one database to indicate the portions of the electronic 
order data that have been rejected. 

20. The computer implemented method of claim 16, wherein the electronic 
sales order data is in Electronic Data Interchange format. 

21. A computer program product comprising: 

a computer usable medium having computer readable program code 
embodied in the medium for pre-processing orders before they are transmitted 
to an order processing system, the computer program product having: 

first computer program code for receiving electronic sales order data; 

second computer program code for translating the electronic sales 
order data to an internal format; 
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8 third computer program code for transmitting the electronic sales order 

9 data to an interface system, wherein the interface system performs an 

1 0 availability check to determine the portions of the order interceptor data that 

1 1 can be satisfied; and 

1 2 fourth computer program code for determining if the availability check 

1 3 indication is to transmit at least a portion of the order interceptor data to the 

1 4 order processing system, and, if so, transmitting the designated portions of the 

1 5 electronic sales order data to the order processing system. 

1 22. A computer program product of claim 2 1 , flirther having: 

2 fifth computer program code for processing the electronic sales order 

3 data in accordance with business rules; 

4 sixth computer program code for determining if there arc any 

5 processing problems associated with the electronic sales order data; and 

6 seventh computer program code for providing an indication to at least 

7 one user that the electronic sales order data contains errors or is incomplete. 

1 23. A computer program product of claim 22 further comprising: 

2 eighth computer program code for enabling a user to correct the 

3 electronic sales order data; and 

4 ninth computer program code for transmitting the corrected electronic 

5 sales order data to the order processing system. 

1 24. A computer program product of claim 23 further comprising: 

2 tenth computer program code rejecting the electronic sales order data 

3 that cannot be filled; and 

4 eleventh computer program code for updating at least one database to 
1 indicate the portions of the electronic order data that have been rejected. 
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PRE-PROCESSOR FOR INBOUND SALES ORDER 
REQUESTS WITH LINK TO A THIRD PARTY 
AVAILABLE TO PROMISE (ATP) SYSTEM 

ABSTRACT OF THE DISCLOSURE 

5 A method and apparatus for pre-processing electronic data requests within the 
EDI subsystem layer and within the order fulfillment application system. An 
order interceptor, third-party Available To Promise (ATP) interface, pseudo- 
sales order workbench, and the reject acknowledgment system processes are 
provided within the order fulfillment application system to accomplish the pre- 

10 processing. The order interceptor performs an asynchronous availability check 
before a sales order is posted. The result of the ATP check is stored in an 
ESO, and is applied during the posting process with unique user exits. The 
result of the ATP check is also used to determine key information about the 
sales order, such as the sales organization, and division and distribution 

1 5 channels. The pre-processor uses business rules to determine if the ESQ should 
be split into multiple documents for requests satisfied across multiple sales 
areas. The Workbench provides a customer purchase order view of the ESQ 
that looks, feels and behaves like actual order entry screens. The Workbench 
also displays messages generated from the pre-processor describing why the 

20 ESQ was held for review. After the condition is corrected the Workbench 
re-executes the ESQ pre-processor. This continues until all messages are 
corrected or marked reviewed. The supplier can decide to either accept the 
request, reject the request or accept individual line items. 
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wiijtul talse statements may jeopardize the validity of tfie application Or any patent issued thereon. 



1 of 4 



BU9-99-021 



Inventor: Marion Scott Bright 
Signature: 



Date 



Residence: 9138 Brocklehurst Lane, Charlotte, North Carolina 28215 
Citizenship: U.S.A. 
Post Office Address: Same As Residence 
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^ ' Date 
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Title 37, Code of Federal Regulations, §1. 56(a): 

(a) A duty of candor and good faith toward the Patent and Trademark Office rests on the inventor, on each attorney or agent who 
prepares or prosecutes the plication and on every other individual who is substantively involved in the preparation or prosecution of 
the application and who is associated with the inventor, with the assignee or with anyone to whom there is an obligation to assign the 
application. All such individuals have a duty to disclose to the Office information they are aware of which is material to the examination 
of the application. Such information is material where there is substantial likelihood that a reasonable examiner would consider it 
in^rtant in deciding whether to allow the application to issue as a patent. The duty is commensurate with the degree of involvement 
in the preparation or prosecution of the application. 
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m^wrtant m deciding whether to allow the application to issue as a patent, Tlie duty is commeosuiate with the degree of involvement 
m the preparation or prosecutiou of the application. 
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in iha pfopacatton cr preaaf nrtng of tho aj^kalioft* 



3 of 4 



MrK aa r-K lan TURLINGTON IPLflW 902 7699939 TO 9552BBBB P. 03/19 

(7) Inventor: Jayakuauur iCrishnamurthy 
Signature; - 

Residence: 20 Summer St.» #aoSN, Milden. MassacbuMtts, 02148 
Cttusnchip: India 

Post OCfioe Addftsai Stme Aa Rnidence 

[8) Inventor: jQregoxy Lm McKcn 

Sijcature; ^ 



Dale 

Residence: 8420 Bunit Umber Drivo, Cbarlotta, North Carolina 2821S 
Cjiizonibip; U.S.A. 
Post Offlofi Addmv: Samo As Hotidcnca 
(9) bventor. SyWainMi^d^ 

Raiidencfi: 355 Muoonneuve, StrHuUn, QuebeCp Canada J3Y-7X1 

Cliizsansbip; Canada 
yj Post Office AddTGss: Soma As Residence 
$|0) Inventor: Penny Jeannett6p6Bch0y4CQuntz 

51 Signature: 

CO Dfli* 
. Residence; 84 Oalcwood Driva» South Burllngion, Vormont 0S043 

2 CitlaenBhip: U,S.A- 

PobC Offloe Addnna: Same As RoeidencB 

Inventor: James Donald Scon 

Signature: ^ _ 

Residence: 4908 Prestwick Lane, Charlotte, North Carolina 28212 
GtiTOsUpt U.S.A. 
Post Office Addraaa: Some Aa Residence 



Tide 37, Cods of Fcdoml Regulatlonfi, 91.55(a): 

(a) A duty of cABdor and good faith towanl die patent and Tndemaiic OfUce mia on the InveQiOT, on aacb attoiney or iigent ivho 
pnpaiQB or proafictttea the application and on every Other Individual Who ia substantively involved in the preparation or prosecution of 
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(b) Under this section, information is material to pat^tability vAiqti it is not cumulative to information already of record or being made 
of record in the application, and (1) it establishes, by itself or in combination with other information, a prima facie case of 
unpatentability; or (2) it refutes, or is inconsistent with, a position the applicant takes in: (i) opposing an argument of unpatentability 
relied on by the Office, or (ii) asserting an argument of patentability. 



